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Dit  document  beschrijft  het  functioneel  ontwerp  van  het  Airbase  Operations  War- 
game  versie  III.  In  dit  document  wordt  ten  eerste  uiteengezet  welk  ontwikkelings- 
traject  wordt  gehanteerd  voor  de  ontwikkeling  van  het  AOW-III  systeem.  Vervol- 
gens  wordt  uit  dit  traject  verwezen  naar  het  probleemanalyse  document  en  worden 
de  belangrijkste  bevindingen  op  een  rij  gezet.  Hieruit  blijkt  dat  het  oude  AOW-II 
systeem  uitgebreid  c.q.  aangepast  gaat  worden  op  een  viertal  punten,  te  weten  de 
presentatie  en  bediening  van  het  systeem,  de  interne  functionaliteit  en  tools.  In  de 
daarop  volgende  hoofdstukken  worden  de  punten  stapsgewijs  uitgewerkt. 

Als  eerste  punt  wordt  het  nieuwe  bedieningsprincipe  van  het  AOW-III  systeem 
geintroduceerd.  Hierin  wordt  uiteengezet  dat  het  AOW-III  systeem  wordt  voorzien 
van  een  directe  manipulatie  bedieningsprincipe  en  wordt  voorzien  van  een  nieuwe 
ordermodule. 

Als  tweede  punt  wordt  de  presentatie  van  gegevens  van  het  AOW-III  systeem 
beschreven.  Het  nieuwe  systeem  krijgt  een  grafische  gegevenspresentatie  hetgeen 
het  mogelijk  maakt  meerdere  type  gegevens  gelijktijdig  in  beeld  te  brengen  waar- 
onder  een  tote,  een  map  en  een  ordermodule  waarmee  orders  aan  het  systeem 
gegeven  kunnen  worden.  De  gelijktijdige  gegevenspresentatie  en  de  vemieuwde 
ordermodule  realiseren  een  sneller  systeem  waarmee  de  gebruiker  het  gevoel  krijgt 
het  AOW-systeem  op  een  hoger  managementniveau  te  spelen.  In  feite  wordt  nu 
een  groot  deel  van  de  complexiteit  van  het  AOW-systeem  verborgen  in  de  gebrui- 
kersinterface  die  nu  een  aantal  taken  voor  de  gebruiker  ovemeemt. 

Als  derde  punt  worden  een  aantal  zaken  ten  aanzien  van  de  interne  functionaliteit 
beschreven.  Hierin  wordt  o.a.  Out-of-Area  operaties  genoemd.  Als  vierde  punt 
worden  in  hoofdstuk  6  de  tools  voor  het  AOW-in  systeem  behandeld.  Tenslotte 
volgt  een  overzicht  van  het  uiteindelijke  systeem  dat  voor  ogen  staat  na  voltooiing 
van  het  AOW-III  systeem,  inclusief  een  opsomming  van  de  volgorde  waarin  de 
diverse  aspecten  van  het  AOW-III  systeem  worden  gerealiseerd. 
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Samenvatting 


Dit  document  beschrijft  het  functioned  ontwerp  van  het  Airbase  Operations  War- 
game  versie  III,  In  dit  document  wordt  ten  eerste  uiteengezet  welk  ontwikkelings- 
traject  wordt  gehanteerd  voor  de  ontwikkeling  van  het  AOW-III  systeem.  Vervol- 
gens  wordt  uit  dit  traject  verwezen  naar  het  probleemanalyse  document  en  worden 
de  belangrijkste  bevindingen  op  een  rij  gezet.  Hieruit  blijkt  dat  het  oude  AOW-II 
systeem  uitgebreid  c.q.  aangepast  gaat  worden  op  een  viertal  punten,  te  weten  de 
presentatie  en  bediening  van  het  systeem,  de  interne  functionaliteit  en  tools.  In  de 
daarop  volgende  hoofdstukken  worden  de  punten  stapsgewijs  uitgewerkt. 
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1.  Inleiding 

1.1  Algemeen 

De  Opleidingen  KLu  van  het  Instituut  Defensie  Leergangen  (IDL)  (de  voormalige 
Luchtmachtstafschool)  leidt  via  de  cursus  Hogere  StafVorming  (HSV)  lucht- 
machtofficieren  op  voor  toekomstige  functies  in  de  luchtmachtstaf  en/of  de  basis- 
staf  van  een  vliegbasis. 

In  1985  heeft  men  aan  TNO-FEL  de  opdracht  gegeven  tot  de  ontwikkeling  van  een 
computerondersteund  management  game  van  een  vliegbasis  voor  gebruik  binnen 
de  cursus  HSV.  Dit  heeft  in  1989  geresulteerd  in  de  eerste  versie  van  het  Airbase 
Operations  Wargame  (AOW),  de  stand  alone  versie.  Vanwege  ervaringen  met  het 
gebruik  van  AOW  in  diverse  spelsessies  met  cursisten  van  de  HSV  zijn  er  ver- 
schillende  ontwikkelingen  geweest,  die  in  1993  hebben  geleid  tot  een  tweede 
versie  van  AOW,  de  netwerk  versie. 

In  1994  is  de  gebruikersgroep  van  het  Airbase  Operations  Wargame  uitgebreid  met 
cursisten  van  de  Luitenant-Kolonelscursus  en  is  het  plan  ontstaan  om  het  AOW 
systeem  ook  te  gebruiken  in  de  majoorscursus  (allebei  van  de  Opleidingen  KLu). 
Ervaringen  met  het  gebruik  van  de  bestaande  versie  van  AOW  hebben  in  1994 
geleid  tot  een  behoeftestelling  voor  een  derde  versie  van  het  Airbase  Operations 
Wargame. 

De  ontwikkeling  van  de  software  van  AOW-III  zal  gaan  volgens  de  standaard 
fasering  die  gebruikt  wordt  in  researchgroep  1-3  van  het  TNO-FEL. 

De  volgende  fasen  worden  hierbij  onderscheiden  (incl.  een  beschrijving  van  de 
diverse  te  verschijnen  rapporten): 

1.  Probleemanalyse. 

Produkt:  document. 

Het  document  beschrijft  in  het  jargon  van  de  opdrachtgever  zijn  probleem  en 
geeft  grofweg  de  richting  aan  waarin  de  oplossing  zal  worden  gezocht. 

2.  Functioneel  Ontwerp 
Produkt:  document. 

Het  functioneel  ontwerp  beschrijft  in  het  jargon  van  de  applicatiedeskundige  de 
conceptuele  oplossing  voor  het  probleem.  Daamaast  bevat  het  document  de 
functionele  specificaties  voor  de  te  ontwikkelen  software.  Belangrijke  elemen- 
ten  daarbij  zijn  de  vereiste  invoer  (incl.  bijvoorwaarden)  en  uitvoer  (zowel  pri- 
maire  resultaten  (uitkomst)  als  secundaire  resultaten  (voor  interpretatie  van  de 
resultaten)). 

3.  Systeem/Technisch  Ontwerp 
Produkt:  document  en  prototype. 
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Dit  document  beschrijft  hoe  de  functionele  specificaties  zullen  worden  geVm- 
plementeerd.  Het  bevat  een  beschrijving  van  de  datastnictuur,  de  meest  inge- 
wikkelde  algoritmes  en  de  algehele  programmastructuur. 

4.  Implementatie/Testen 
Produkt:  software. 

5.  Validatie 
Produkt:  document. 

Het  validatie  document  beschrijft  de  wijze  waarop  het  model  gevalideerd  is. 

Het  bevat  de  aanpak,  de  invoergegevens,  de  resultaten  en  de  analyses  (bv.  de 
gevoeligheid)  van  de  validatie. 

Het  validatierapport  kan  de  latere  gebruikers  helpen  modelresultaten  op  de 
juiste  wijze  te  kunnen  interpreteren. 

6.  Aflevering  /  Onderhoud 
Produkt:  documenten  en  software. 

De  user-documentatie  bestaat  uit  een  handleiding  bij  het  gebruik  van  het  model. 
Standaard  bevat  een  handleiding  een  beschrijving  van  alle  features  in  het  pro- 
gramma,  een  installatie  procedure  en  referentie  informatie  om  met  het  model  te 
kunnen  werken  (een  gecombineerde  user-  en  reference  manual  dus). 

Het  source-code-rapport  is  bedoeld  om  een  voltooide  versie  zo  te  registreren  dat 
versiebeheer,  overdraagbaarheid  en  onderhoud  in  belangrijke  mate  vergemak- 
kelijkt  wordt.  Het  source-code  rapport  bevat  alle  sources  van  het  programma, 
een  cross-reference,  een  programma-structuur  overzicht,  de  manier  waarop  een 
versie  kan  worden  aangemaakt,  welke  files  benodigd  zijn  om  het  programma  te 
kunnen  runnen,  etc. 

Kenmerk  van  het  rapport  is  dat  het  een  groeidocument  behoort  te  zijn.  Het  kost 
dan  weinig  tijd  om  het  te  produceren  en  geeft  veel  gemak  tijdens  de  ontwikke- 
ling. 

De  genoemde  rapporten  behorend  bij  de  diverse  fasen  zullen  achtereenvolgens 
worden  geproduceerd.  Voor  alle  rapporten  (eventueel  met  uitzondering  van  het 
systeem/technisch  ontwerp  document)  geldt  dat  zij  ter  goedkeuring  aan  de  op- 
drachtgever  worden  aangeboden. 

Ook  voor  AOW-III  geldt  dat  deze  documenten  zullen  worden  geschreven. 

Dit  rapport  is  een  weergave  van  fase  2:  het  functioned  ontwerp. 


1.2  Aanpak  functioneel  ontwerp 

Allereerst  wordt  in  hoofdstuk  twee  de  doelstelling  van  het  AOW-III  systeem 
weergegeven  met  verwijzingen  naar  het  probleemanalyse-rapport  [1].  Op  basis  van 
de  doelstellingen  en  de  bevonden  problemen  uit  de  probleemanalyse  wordt  in  de 
hoofdstukken  drie  tot  en  met  zes  een  oplossingsrichting  geschetst  waarbij  het 
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AOW  systeem  uitgewerkt  op  een  viertal  punten:  bediening,  schermpresentatie, 
interne  functionaliteit  en  tools,  Hoofdstuk  negen  toont  een  overzicht  van  de  nieu- 
we  systeemopzet  van  het  AOW-III  systeem. 
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2.  Introductie  AOW-III 


Dit  hoofdstuk  geeft  een  beschrijving  van  het  AOW-II  systeem  naar  aanleiding  van 
het  probleem-analyse  rapport  [1]  en  distilleert  hieruit  de  doelstelling  tot  het  nieuwe 
AOW-III  systeem,  Daamaast  vormt  dit  hoofdstuk  een  introductie  op  de  hoofdstuk- 
ken  drie  tot  en  met  zes  waarin  de  punten  uit  dit  hoofdstuk  uitgewerkt  worden. 


2. 1  Probieemanalyse 

Resumerend  blijkt  uit  het  probleemanalyse-document  van  het  AOW-II  systeem  dat 
de  bevonden  problemen  zich  concentreren  rond  (a)  de  gegevenspresentatie,  (b)  de 
bediening,  (c)  het  interne  AOW-simulatiesysteem  en  (d)  tools  voor  het  AOW- 
systeem.  De  omgang  met  de  huidige  AOW-II  gebruikersinterface  is  te  arbeidsin- 
tensief  waardoor  de  gebruikers  de  functie  niet  ervaren  als  management  niveau.  De 
oorzaak  hiervan  wordt  gevonden  in  de  opzet  van  het  AOW-II  systeem.  Deze  is 
ontstaan  uit  de  noodzaak  om  het  programma  te  kunnen  draaien  op  de  vorige  gene- 
ratie  pc's  (zogenaamde  80286  pc's).  Hierdoor  was  een  strikte  scheiding  van  het 
programma  in  onderdelen  noodzakelijk  om  tot  een  acceptabel  snel  functionerend 
systeem  te  komen.  De  nadelige  gevolgen  van  de  oude  opzet  volgt  uit  een  voorbeeld 
bij  het  geven  van  een  order:  de  gebruiker  moet  de  informatie-modules  (tote  of 
map)  benaderen  en  de  gevonden  gegevens  opschrijven;  vervolgens  wordt  overge- 
schakeld  naar  de  ordermodule  en  worden  de  opgeschreven  gegevens  hier  in  een 
order  verwerkt.  Deze  arbeidsintensieve  wijze  van  werken  kan  nu  opgelost  worden 
door  de  huidige  generatie  snellere  pc's  (zogenaamde  80486  en  Pentium  pc's). 
Hierdoor  kan  voor  een  andere  systeemopzet  gekozen  worden  die  weliswaar  meer 
rekenkracht  vraagt  van  de  pc  maar  de  hierboven  geschetste  problemen  oplost. 

Bij  het  AOW-II  systeem  is  sprake  van  een  verticale  verzuiling  van  de  systeem- 
componenten:  zie  figuur  2.1.  Dit  betekent  dat  de  in  het  AOW-II  systeem  aanwezige 
modules  apart  benaderd  moeten  worden  en  dat  per  keer  slechts  een  module  actief 
kan  zijn.  Om  de  bediening  van  het  systeem  te  verbeteren  moeten  deze  zuilen 
worden  geintegreerd. 


TNO-rapport 


FEL-96-A284 


Figuur  2. 1:  Verticale  verzuiling  in  het  AOW-U  systeem  van  de  systeemcomponenten. 


Het  doel  is  nu  om  over  te  stappen  van  een  verticale  verzuiling  naar  een  horizontale 
groepering:  zie  figuur  2.2.  Om  dan  de  complexiteit  van  het  totale  systeem  te  be- 
heersen  wordt  een  presentatie-manager  gei'ntroduceerd  die  als  interface  fungeert 
tussen  de  gebruiker  en  het  AOW-systeem.  Door  de  horizontale  groepering  zijn  de 
modules  altijd  tegelijk  bereikbaar  zonder  om  te  schakelen  hetgeen  de  bediening  ten 
goede  komt. 


Figuur  2.2:  Horizontale  groepering  in  het  AOW-IIl  systeem  van  de  systeemcomponenten. 
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Naast  de  problemen  van  de  presentatie  van  gegevens  en  de  bediening  van  het 
AOW-systeem  zijn  problemen  geconstateerd  rond  het  AOW-simulatiesysteem. 
Deze  bevatten  opmerkingen  rond  de  working  van  het  AOW-II  systeem:  de  werk- 
druk  van  de  spelers  is  bijvoorbeeld  verschillend  per  tijdsperiode,  het  terugroepen 
van  personeel  van  een  taak  in  geval  van  gewijzigde  prioriteitstelling  is  niet  moge- 
lijk,  etc.  Daamaast  bestaat  behoefte  aan  een  aantal  tools  voor  het  zelf  ontwerpen 
van  vliegbases  (wat  betreft  infrastructuur,  organisatiestructuur  en  management- 
structuur)  en  scenario's. 

Resumerend  kunnen  de  bevonden  problemen  worden  ingedeeld  in  vier  categorie- 
en: 

1.  presentatie  van  gegevens; 

2.  bediening  van  het  AOW-systeem; 

3.  interne  functionaliteit  van  het  AOW-systeem; 

4.  tools. 

Deze  vier  categorieen  vormen  de  vier  hoofdpunten  van  dit  document.  Voor  een 
uitgebreid  overzicht  van  de  bevonden  problemen  wordt  verwezen  naar  het  pro- 
bleemanalyse-rapport  [1]. 


2-2  Doelstelling 

De  doelstelling  is  ten  eerste  de  vier  bevonden  problemen  uit  paragraaf  2.1  te 
verhelpen.  De  algemene  doelstelling  luidt  om  te  komen  tot  een  systeem  waarbij  de 
gebruiker  het  idee  heeft  dat  hij  de  controle  over  de  bediening  van  het  systeem 
zodanig  beheerst  zodat  hij  zich  volledig  kan  concentreren  op  het  simulatiespel  zelf, 
in  plaats  van  op  de  bediening  van  het  systeem.  Het  systeem  moet  voor  de  gebruiker 
snel  te  leren  en  goed  te  onthouden  zijn.  Daamaast  moet  de  gebmiker  een  gevoel 
van  beheersing  van  het  systeem  hebben  en  vertrouwen  in  de  taakuitvoering  heb- 
ben.  Dit  impliceert  dat  het  systeem  prettig  in  de  omgang  moet  zijn  waarbij  het 
AOW-systeem  is  voorzien  van  een  modem  gebruikersinterface  en  beschikt  over 
een  nieuw  principe  voor  het  invoeren  van  gegevens.  De  volgende  paragrafen 
werken  de  doelstelling  uit  op  de  vier  gedetermineerde  categorieen  uit  paragraaf 
2.1. 

2.2.1  Bediening 

Ten  opzichte  van  het  AOW-II  systeem  zullen  er  in  het  AOW-III  systeem  geen 
diepe  menustmcturen  meer  gebmikt  worden.  Alle  functies  binnen  het  AOW- 
systeem  zullen  bereikbaar  zijn  via  buttons  (knoppen)  die  op  het  scherm  geplaatst 
zijn.  Op  deze  buttons  is  de  gehele  AOW-II  menustmctuur  platgeslagen  waardoor 
een  snelle  en  overzichtelijke  bedieningsmodule  ontstaat,  De  buttons  zijn  op  het 
scherm  te  bedienen  door  een  muispijl  die  met  een  muis  bediend  wordt  (een  muis- 
pijl  is  een  pijl  op  het  beeldscherm  die  met  behulp  van  een  muis  over  het  scherm 
bewogen  kan  worden;  er  kunnen  bijvoorbeeld  buttons  mee  'ingedrukt'  worden). 
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Ten  tweede  worden  de  diverse  gegevens  gepresenteerd  in  windows.  Een  window  is 
een  afgebakend  gebied  op  het  scherm  waarin  een  bepaald  type  informatie  wordt 
weergegeven,  zoals  een  tote,  een  map  of  een  ordermodule.  Met  het  AOW-III 
systeem  is  het  mogelijk  om  tussen  de  windows  gegevens  (objecten)  over  te  dragen. 
Zodoende  is  het  mogelijk  om  objecten  uit  een  tote  of  een  map  over  te  dragen  naar 
de  ordermodule  of  een  clipboard  om  zodoende  op  een  eenvoudige  manier  orders  te 
geven.  Een  clipboard  is  een  verzamelbak  voor  alle  gegevens  die  de  gebruiker 
selecteert  en  wil  bewaren:  geselecteerde  objecten  kunnen  bewaard  worden  in  een 
clipboard. 

Ten  derde  geeft  het  systeem  support  bij  het  geven  van  orders.  Zo  zal  het  systeem 
aan  kunnen  geven  welke  orders  gegeven  kunnen  worden  wanneer  de  gebruiker  een 
object  uit  een  map  of  een  tote  aanwijst  met  de  muispijl. 

Hoofdstuk  drie  beschrijft  de  exacte  bedieningsmethodieken  van  het  AOW«in 
systeem. 

2.2.2  Presentatie 

Voor  de  acceptatie  van  een  nieuw  systeem  is  een  positief  oordeel  op  een  drietal 
punten  noodzakelijk,  te  weten  de  consistentie,  de  appreciatie  en  de  functionaliteit 
van  het  systeem. 

Ten  eerste  moet  op  alle  punten  in  het  AOW-III  systeem  een  hoge  mate  van  consis¬ 
tentie  gelden.  Dit  geldt  voor  de  schermpresentatie,  bediening  en  omgang  met  het 
systeem,  als  ook  het  interne  deel  van  het  systeem.  Door  dit  toe  te  passen  op  het 
systeem  zal  sprake  zijn  van  een  duidelijke  en  herkenbare  opbouw  (ook  bij  applica- 
ties  onderling)  waardoor  de  inwerktijd  van  de  gebruiker  korter  zal  zijn.  Daamaast 
geeft  het  een  net  en  verzorgd  uiterlijk  waarbij  de  gebruiker  niet  snel  voor  verras- 
singen  van  de  gebruikersinterface  komt  te  staan. 

De  appreciatie  of  de  waardering  voor  een  systeem  vloeit  voort  uit  een  aantal  items 
waaronder  de  meest  belangrijke  de  uitstraling  en  de  identiteit  van  het  systeem  zijn. 
De  uitstraling  van  het  systeem  bepaalt  of  de  gebruiker  het  systeem  waardeert 
danwel  verafschuwt.  De  uitstraling  wordt  in  de  eerste  plaats  bepaald  door  het 
voorkomen  van  het  systeem  (netheid)  en  ten  tweede  door  de  functionaliteit  van  het 
systeem  (hoe  doeltreffend  werkt  het  systeem).  De  identiteit  van  het  systeem  wordt 
gevonden  in  de  algemene  schermpresentatie  en  de  bediening  van  het  systeem.  De 
herkenbaarheid  van  deze  twee  punten  in  andere  programma’s  geeft  inhoud  aan  de 
term  identiteit.  Het  AOW-III  systeem  dient  een  duidelijke  identiteit  en  uitstraling 
te  hebben. 

Ten  derde  dient  de  functionaliteit  van  het  systeem  niets  te  wensen  over  te  laten.  Bij 
het  AOW-III  systeem  geldt  dat  het  scherm  opgebouwd  zal  zijn  uit  functionele 
gebieden  waarin  elk  gebied  zijn  eigen  type  functie  heeft.  Er  wordt  gebruik  gemaakt 
van  windows  die  informatie  tonen  aan  de  gebruiker  zoals  een  map  of  een  tote. 
Daamaast  is  een  deel  van  het  scherm  gereserveerd  voor  de  ordermodule.  Het 
principe  is  dat  een  aantal  modules  uit  het  AOW-systeem  gelijktijdig  op  het  scherm 
gepresenteerd  worden. 

Tenslotte  wordt  opgemerkt  dat  ten  aanzien  van  de  presentatie  en  de  bediening  een 
groot  deel  van  de  complexiteit  van  het  AOW-systeem  wordt  verborgen  in  de 
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gebruikersinterface.  Hierdoor  krijgt  de  gebruiker  een  relatief  eenvoudig  bedie- 
nings-  en  presentatiesysteem  waarbij  vele  (complexe)  handelingen  door  de  gebrui- 
kersinterface  worden  opgevangen.  Dit  ontlast  de  gebruiker  waardoor  deze  meer 
tijd  heeft  voor  het  daadwerkelijk  speien  van  het  AOW-systeem. 

2.2.3  Interne  functionaliteit 

Behalve  de  in  paragraaf  2.1  genoemde  problemen  met  het  simulatie-gedeelte  van 
het  AOW-II  systeem  (zoals  verschillende  werkdruk  van  spelers  per  tijdsperiode) 
zullen  er  op  zich  geen  principes  aangepast  of  gewijzigd  worden  uit  het  AOW-II 
systeem  voor  het  AOW-III  systeem  wat  betreft  de  interne  functionaliteit.  Er  zijn 
echter  wel  een  aantal  eigenschappen  voor  het  AOW-III  systeem  die  thans  ontbre- 
ken  of  slechts  gedeeltelijk  geimplementeerd  zijn  Het  betreft  de  volgende  punten: 

•  Onderbreken  werkzaamheden 

Het  moet  mogelijk  zijn  om  werkzaamheden  te  kunnen  onderbreken  zodat  een 
lopende  taak  door  de  gebruiker  afgebroken  kan  worden.  Zodoende  is  het  bij- 
voorbeeld  mogelijk  om  de  gebruikte  middelen  van  een  afgebroken  proces  in  te 
zetten  op  een  taak  met  hogere  prioriteit  (indien  de  gebruiker  dit  wil). 

•  Electronic  mail 

De  electronic-mail  faciliteit  zal  uitgebreid  worden  tot  een  systeem  met  twee 
mailpool's  in  plaats  van  een  mailpool  waarin  alle  boodschappen  geplaatst  wer- 
den.  Bij  het  nieuwe  Email-systeem  wordt  onderscheidt  gemaakt  tussen  AOW- 
boodschappen  en  gebruikers-boodschappen. 

•  Werkdruk 

Voor  de  spelers  OLD  en  CGROD  is  de  werkdruk  te  laag.  Dit  kan  voor  de  speler 
CGROD  bijvoorbeeld  verhoogd  worden  door  meer  detail  aan  te  geven  bij 
grondgevechten. 

Hoofdstuk  vijf  behandelt  de  veranderingen  op  de  interne  functionaliteit  binnen  het 
AOW-III  systeem. 

2.2.4  Tools 

Tenslotte  zijn  een  aantal  tools  naast  het  AOW-systeem  gewenst  voor  het  samen- 
stellen  van  eigen  vliegbases  (wat  betreft  infrastructuur,  organisatiestructuur  en 
managementstructuur)  en  om  zelf  scenario's  te  maken.  In  principe  staan  tools 
geheel  los  van  het  AOW-systeem  en  zijn  puur  bedoeld  voor  het  voorbereiden  van 
sessies  of  voor  het  nabespreken  van  sessies. 

Ten  aanzien  van  evaluatie-mogelijkheden  is  het  tot  op  heden  niet  expliciet  moge¬ 
lijk  geweest  om  na  afloop  van  een  spelsessie  de  behaalde  resultaten  uit  te  drukken 
in  een  waardering  en  op  basis  hiervan  een  evaluatie  te  houden.  Met  het  AOW-II 
systeem  wordt  momenteel  na  afloop  een  discussie  opgestart  met  de  docenten  en  de 
gebruikers  om  de  behaalde  resultaten  te  bespreken.  Ondersteuning  hierbij  met  een 
door  AOW-III  gegenereerde  evaluatie  kan  een  waardevolle  aanvulling  zijn. 

De  hoofdstukken  zes,  zeven  en  acht  werken  een  aantal  tools  uit  voor  het  AOW- 
systeem. 
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3.  Bediening  van  het  AOW-III  systeem 


Het  streven  is  een  AOW-III  systeem  te  ontwerpen  dat  eenvoudig  te  bedienen  is 
door  de  gebruiker  vanwege  de  logische  opbouw  van  de  gebruikersinterface  en  een 
goede  overzichtelijke  presentatie  van  de  gegevens.  Daamaast  moet  het  systeem  een 
aantai  taken  automatiseren  die  normaal  gesproken  door  de  gebruiker  verricht 
moeten  worden  zoals  het  geven  van  orders  aan  het  systeem.  Hierbij  zou  het  moge- 
lijk  moeten  zijn  opgevraagde  informatie  direct  in  orders  te  verwerken  zonder  dat 
het  omschakelen  tussen  modules  noodzakelijk  is  (zoals  dat  nu  in  het  AOW-II 
systeem  het  geval  is).  Wellicht  ten  overvloede  zij  vermeld  dat  in  dit  document 
alleen  de  spelerstations  en  het  staff-station  worden  behandeld.  Het  simulatie- 
station  valt  voorlopig  buiten  beschouwing  daar  deze  geen  of  nauwelijks  een  vorm 
van  bediening  kent.  In  totaal  is  dus  sprake  van  drie  type  stations  waarvan  een 
station  (het  simulatie-station)  buiten  beschouwing  wordt  gelaten. 


3.1  Bedieningsprincipe 

Qua  bediening  krijgt  de  gebruiker  de  grootst  mogelijke  vrijheid  in  de  vorm  van 
directe  manipulatie.  Met  dit  principe  kan  de  gebruiker  een  muispijl  (een  pijl  op  het 
scherm  die  wordt  aangestuurd  door  een  muis)  vrij  over  het  scherm  bewegen  en 
buttons  (gebieden)  op  het  scherm  aanklikken  die  een  bepaalde  actie  voorstellen, 
zoals  het  lezen  van  mail  of  het  inzoomen  op  een  map.  Het  principe  van  directe 
manipulatie  geeft  een  gevoel  van  beheersing  over  de  bediening  van  het  systeem, 
vertrouwen  in  de  taakuitvoering,  het  is  snel  te  leren  en  goed  te  onthouden.  Directe 
manipulatie  is  gebaseerd  op  drie  principes: 

•  Huidige  objecten  en  acties  zijn  continu  in  beeld 

Alle  objecten  en  opdrachten  die  de  gebruiker  aan  het  systeem  kan  geven  zijn 
continu  in  beeld  gebracht  in  de  vorm  van  buttons  of  objecten  (een  object  is  bij- 
voorbeeld  een  building  op  de  map).  Voor  het  uitvoeren  van  een  opdracht  hoeft 
de  gebruiker  alleen  de  muispijl  op  een  van  deze  buttons  of  objecten  te  plaatsen 
en  aan  te  klikken. 

•  Fysieke  acties  en  knop  'indrukken '  in  plaats  van  een  complete  syntax 
Wanneer  een  button  of  object  wordt  geselecteerd  dan  gebeurt  hier  zichtbaar  iets 
mee  zodat  de  gebruiker  weet  dat  zijn  opdracht  aan  het  systeem  is  waargenomen 
of  wordt  verwerkt.  Zo  kan  een  button  optisch  verzinken  als  deze  wordt  'inge- 
drukt'  door  een  3D-effect. 

•  Snelle,  incrementele,  eenvoudig  omkeerbare  acties,  waarvan  het  gevolg  direct 
zichtbaar  is 

Alle  acties  zijn  eenvoudig  afbreekbaar  middels  een  canc^Z-button.  Wanneer  de 
gebruiker  tijdens  een  actie  tot  het  besluit  komt  deze  niet  af  te  maken  dan  kan 
middels  de  cancel-hnXion  de  gehele  actie  afgebroken  worden  zonder  dat  dit 
consequenties  heeft  voor  het  systeem.  Deze  wijze  van  werken  is  uitermate  een- 
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voudig  en  prettig  voor  de  gebruiker  omdat  deze  de  gekozen  actie  altijd  kan  af- 
breken  zonder  dat  dit  consequenties  heeft.  Dit  principe  levert  een  flexibel  sys- 
teem. 


3,2  De  Look  en  Feel  van  het  systeem 

De  look  en  feel  van  het  systeem  heeft  betrekking  op  het  feit  hoe  de  gebruiker  de 
omgang  met  het  systeem  ervaart  en  in  welke  mate  de  gebruiker  het  systeem  ac- 
cepteert.  Voor  de  acceptatie  van  een  nieuw  systeem  is  een  positief  oordeel  op  een 
drietal  punten  noodzakelijk,  te  weten  de  consistentie,  de  appreciatie  en  de  functio- 
naliteit  van  het  systeem. 

Consistentie 

Door  het  gebruik  van  een  Windows-look-alike  gebruikersinterface  en  door  dit 
stringent  toe  te  passen  ontstaat  een  gebruikersinterface  die  consistent  is  qua  op- 
bouw  en  bediening,  De  gebruiker  weet  zodoende  wat  verwacht  kan  worden  als 
deze  een  actie  ondemeemt,  zoals  een  actie  waarbij  met  de  muispijl  op  een  button 
wordt  gedrukt. 

Appreciatie 

De  Windows-look-alike  gebruikersinterface  geeft  een  nette  schermopbouw.  De 
logische  schermopbouw  met  duidelijk  ingedeelde  functionele  blokken  geeft  een 
duidelijke  uitstraling  wat  de  netheid  en  de  identiteit  van  het  systeem  ten  goede 
komt. 

Functionaliteit 

Bij  het  AOW-III  systeem  geldt  dat  het  scherm  opgebouwd  zal  zijn  uit  functionele 
gebieden  waarin  elk  gebied  zijn  eigen  type  functie  heeft.  Er  wordt  gebruik  gemaakt 
van  windows  die  informatie  tonen  aan  de  gebruiker  zoals  een  map  of  een  tote. 
Daamaast  is  een  deel  van  het  scherm  gereserveerd  voor  de  ordermodule.  Het 
principe  is  dat  een  aantal  modules  uit  het  AOW-systeem  gelijktijdig  op  het  scherm 
gepresenteerd  worden. 


3.3  Invoeren  van  orders 

Een  van  de  belangrijkste  aspecten  van  het  AOW-systeem  voor  de  gebruiker  is  het 
raadplegen  van  gegevens  en  vervolgens  het  geven  van  orders.  Omdat  deze  actie 
veelvuldig  wordt  verricht  is  dit  een  actie  die  zo  soepel  en  flexibel  mogelijk  moet 
verlopen.  Het  invoeren  van  gegevens  (orders)  aan  het  AOW-III  systeem  zal  zo 
flexibel  mogelijk  plaatsvinden  en  waar  het  kan  geautomatiseerd  worden.  Het 
invoeren  van  orders  kan  voor  een  belangrijk  stuk  geautomatiseerd  worden  door 
opgevraagde  informatie  van  objecten  direct  te  verwerken  in  een  order-dialoog.  In 
vergelijking  met  het  AOW-III  systeem  heeft  het  AOW-II  systeem  een  interactie- 
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principe  dat  gebaseerd  is  op  menu's  en  het  invullen  van  zogenaamde  formulieren 
(dit  zijn  uitgebreide  dialogen  waarbij  veel  gegevens  ingevuld  moeten  worden).  De 
menu’s  hebben  bij  het  AOW-II  systeem  een  diepe  gelaagdheid  en  vaak  moet  de 
gebruiker  zoeken  naar  de  juiste  menu-keuze.  Het  geven  van  orders  geschiedt  door 
het  invullen  van  formulieren  met  gegevens  die  van  te  voren  zijn  opgezocht  in  de 
totes  of  de  maps. 

Het  AOW-III  systeem  krijgt  een  interactie-principe  dat  gebaseerd  is  op  het  selecte- 
ren  van  objecten  uit  de  totes  en/of  de  maps  waarbij  orders  gegenereerd  kunnen 
worden.  Het  AOW-III  systeem  assisteert  de  gebruiker  dus  bij  het  geven  van  orders. 
Het  achterliggende  principe  bij  deze  ondersteuning  is  dat  het  AOW-III  systeem 
zelfstandig  orders  selecteert  die  met  behulp  van  de  geselecteerde  objecten  gegeven 
kunnen  worden.  Zo  zal  het  AOW-III  systeem  zichtbaar  automatisch  de  order 
Repair  Runway  aanbieden  indien  de  gebruiker  damaged  runways  heeft  geselec- 
teerd.  Het  systeem  geeft  dus  direct  aan  welke  orders  mogelijk  zijn  met  de  geselec¬ 
teerde  objecten.  Dit  principe  is  een  stuk  automatisering  vanuit  het  systeem  dat  de 
gebruiker  assisteert  bij  het  geven  van  opdrachten  (orders).  De  doelstelling  is  dat  de 
gebruiker  het  geven  van  opdrachten  op  een  hoger  managementsniveau  ervaart. 

Het  invoeren  van  orders  kan  op  diverse  manieren  gebeuren.  In  totaal  zullen  er  vier 
manieren  zijn  om  orders  aan  het  systeem  te  geven,  te  weten: 

L  Aanklikken  van  een  order 

Een  manier  van  orders  geven  die  overeenkomt  met  het  AOW-II  systeem  is  het 
aanklikken  van  een  order  in  de  orderwindow  (orderwindow:  zie  paragraaf  4,3.4). 
Deze  manier  van  orders  geven  kan  gekozen  worden  als  de  gebruiker  expliciet  weet 
welke  order  er  gegeven  moet  worden.  De  orderwindow  is  een  gebied  op  het 
scherm  waarin  de  ordermodule  wordt  gepresenteerd.  Op  die  manier  zal  een  pop-up 
window  verschijnen  waarin  de  parameters  van  de  order  ingevuld  kunnen  worden. 
Hiema  kan  de  order  aan  het  AOW-simulatiesysteem  worden  doorgegeven.  Deze 
wijze  van  orders  geven  is  identiek  aan  de  wijze  uit  het  AOW-II  systeem,  zij  het 
echter  sneller  omdat  de  gebruiker  sneller  de  benodigde  informatie  kan  achterhalen. 

2.  Na  het  opvragen  van  informatie 

Wanneer  de  gebruiker  van  het  AOW-systeem  bezig  is  met  het  oproepen  van  infor¬ 
matie  van  bijvoorbeeld  objecten  uit  een  map  dan  is  het  denkbaar  dat  de  gebruiker 
met  de  opgeroepen  gegevens  een  order  aan  het  AOW-systeem  wil  geven.  Indien  de 
gebruiker  na  het  oproepen  van  de  informatie  een  order  aanklikt  dan  worden  de 
meest  relevante  gegevens  uit  de  opgeroepen  informatie  al  bij  de  order-parameters 
ingevuld  indien  het  object  voldoende  affiniteit  heeft  met  de  order.  Zodoende  wordt 
de  gebruiker  geassisteerd  bij  het  geven  van  een  order  en  zijn  het  aantal  stappen  dat 
moet  worden  genomen  voor  het  geven  van  een  order  geminimaliseerd. 

3.  Na  het  selecteren  van  objecten 

De  gebruiker  heeft  de  mogelijkheid  willekeurig  meerdere  objecten  te  selecteren  in 
een  map  of  een  tote.  Aan  de  hand  van  de  objecten  die  door  de  gebruiker  zijn  gese- 
lecteerd  zal  het  AOW-systeem  orders  selecteren  die  gegeven  kunnen  worden  met 
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de  geselecteerde  objecten.  Indien  de  gebruiker  nu  een  order  aanklikt  dan  worden 
alle  relevante  objecten  verwerkt  in  de  order.  Zodoende  kan  de  gebruiker  bijvoor- 
beeld  snel  een  runway  repareren  door  een  aantal  disturbances  te  selecteren  en 
vervolgens  de  order  Repair  Runway  te  geven.  Er  kan  hierbij  een  prioriteit  aange- 
geven  worden:  het  als  eerste  geselecteerde  object  zal  als  eerste  verwerkt  worden  in 
een  order, 

4.  Clipboard 

Objecten  die  de  gebruiker  selecteert  kunnen  ook  overgebracht  worden  naar  het 
clipboard,  Het  clipboard  is  een  soort  geheugen  in  het  AOW-systeem  waarin  aller- 
hande  objecten  uit  de  tote  en  de  map  in  opgeslagen  kunnen  worden.  Naderhand 
kan  de  gebruiker  met  de  objecten  uit  het  clipboard  orders  gaan  geven.  Zodoende  is 
het  niet  noodzakelijk  om  direct  orders  te  geven  met  objecten  die  de  gebruiker 
geselecteerd  heeft.  Het  clipboard  is  dus  een  soort  (semi-permanente)  lijst  van  door 
de  gebruiker  geselecteerde  objecten. 


3.4  Objecten:  selecteren  &  orders  geven  of  informatie  opvragen 

De  gebruiker  kan  twee  dingen  doen  met  objecten  uit  de  totes  en  de  maps:  selecte¬ 
ren  of  informatie  opvragen.  De  gebruiker  kan  dit  met  behulp  van  de  muisknoppen 
aangeven:  indien  een  object  met  de  linker  muisknop  wordt  aangeklikt  dan  zal  het 
object  geselecteerd  worden;  indien  een  object  met  de  rechter  muisknop  wordt 
aangeklikt  dan  wordt  informatie  over  het  object  gegeven. 

Selecteren 

Een  eerste  manier  om  een  object  te  selecteren  is  om  deze  met  de  linker  muisknop 
aan  te  klikken.  Een  geselecteerde  object  op  de  map  wordt  weergegeven  door  een 
opvallende  cirkel  om  het  object  heen;  in  de  tote  wordt  een  geselecteerde  regel  in 
de  kleur  blauw  weergegeven.  Wanneer  een  object  geselecteerd  wordt  dan  zal  de 
ordermodule  direct  die  order(s)  selecteren  die  met  de  geselecteerde  objecten 
mogelijk  zijn,  De  gebruiker  kan  nu  dus  een  order  geven  of  de  geselecteerde  objec¬ 
ten  kopieren  naar  het  clipboard.  Een  object  dat  eenmaal  geselecteerd  is  kan  weer 
gedeselecteerd  worden  door  een  ander  object  te  selecteren  of  in  de  map  een  locatie 
aan  te  klikken  waar  zich  geen  objecten  bevinden. 

Een  tweede  manier  om  objecten  te  selecteren  is  door  een  selectbox  op  de  map  te 
creeren.  Dit  gebeurt  automatisch  door  met  de  muispijl  in  een  map  te  gaan  staan,  de 
linker  muisknop  in  te  drukken  en  de  muispijl  over  de  map  te  verplaatsen:  nu  zal 
een  selectbox  gecreeerd  worden.  Alle  objecten  die  in  dit  gebied  vallen  worden  nu 
automatisch  geselecteerd. 

Figuur  3.1  toont  een  overzicht  van  gebeurtenissen  die  zich  in  het  AOW-III  systeem 
afspelen  bij  het  selecteren  van  objecten  en  het  genereren  van  orders.  De  gebruiker 
selecteert  een  object  waarbij  het  AOW-systeem  direct  die  order(s)  die  met  het 
object  mogelijk  zijn  selecteert  en  toont.  Indien  meerdere  type  objecten  geselec¬ 
teerd  worden  dan  worden  het  totaal  overzicht  gepresenteerd.  Wanneer  de  gebruiker 
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objecten  geselecteerd  heeft  dan  kan  hij  hiermee  een  order  geven  of  hij  kan  de 
objecten  kopieren  naar  het  clipboard  voor  later  gebruik. 


Figuur  3.1:  Activiteiten  in  het  AOW-III  systeem  hij  het  selecteren  van  objecten  en  het 
genereren  van  orders. 


Informatie  opvragen 

Indien  de  gebruiker  een  object  met  de  rechter  muisknop  aanklikt  dan  wordt  uitge- 
breide  informatie  over  het  object  gegeven.  Deze  informatie  (indien  aanwezig) 
wordt  weergegeven  in  een  pop-up  window. 
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4.  Presentatie  van  het  AOW-III  systeem 

Dit  hoofdstuk  beschrijft  hoe  het  AOW-III  systeem  de  gegevens  presenteert  met  als 
basis  de  bedienings-eigenschappen  die  in  hoofdstuk  drie  zijn  beschreven. 

Een  van  de  belangrijkste  onderdelen  van  het  AOW-systeem  zijn  de  totes,  maps  en 
de  orders.  Hiermee  wordt  het  AOW-spel  immers  gespeeld.  Ter  herinnering:  bij  het 
AOW-n  systeem  worden  de  totes  en  maps  afzonderlijk  bekeken  op  informatie 
waama  de  ordermodule  opgestart  wordt  om  orders  te  geven,  indien  daartoe  de 
noodzaak  bestaat.  Men  vindt  deze  wijze  van  werken  te  arbeidsintensief,  te  veel 
switchen  is  noodzakelijk  tussen  schermen  en  men  moet  te  veel  gegevens  opschrij- 
ven.  Hieruit  blijkt  dat  de  toegang  tot  de  modules  niet  optimaal  is.  De  gebruiker 
moet  daarom  een  continu  overzicht  hebben  van  alle  relevante  informatie  uit  het 
AOW-systeem  zonder  dat  omschakelen  tussen  modules  noodzakelijk  is.  Dit  impli- 
ceert  dat  gelijktijdig  een  map  en  een  tote  zichtbaar  moeten  zijn.  Daamaast  moet  de 
gebruiker  direct  toegang  hebben  tot  de  ordermodule. 

Het  scherm  moet  logisch  ingedeeld  zijn  met  duidelijk  gegroepeerde  gebieden: 
gebieden  met  een  bepaalde  functionaliteit  dienen  op  logische  plaatsen  te  staan; 
belangrijke  gegevens  dienen  opvallend  geplaatst  te  worden.  Daamaast  moeten 
mstige  schermkleuren  gebmikt  worden  die  niet  afleiden  of  storend  werken  en  die 
per  gebruiker  apart  instelbaar  zijn.  Tenslotte  moet  de  bediening  en  presentatie  van 
het  AOW-III  systeem  uitermate  consistent  van  aard  zijn  zodat  de  gebruiker  een 
goede  feeling  met  het  systeem  kan  krijgen.  Dit  verhoogt  het  vertrouwen  in  het 
systeem  en  mogelijk  ook  het  plezier  in  het  werken  met  het  systeem  omdat  de 
gebruiker  het  systeem  ’door  heeft'.  Zodoende  zal  de  gebruiker  ook  bij  een  nieuw 
programma  zich  al  snel  thuisvoelen  in  de  bediening  ervan. 

Een  tweede  gegevenspresentatie-aspect  is  het  definieren  van  bevoegdheden  van 
spelers  tot  op  object-niveau.  In  de  AOW-systemen  I  en  II  was  dit  op  het  niveau  van 
totes  en  maps;  in  het  AOW-III  systeem  zullen  objecten  uit  de  totes  en  maps  wel  of 
niet  getoond  op  basis  van  de  spelersfunctie. 


4.1  Principes 

Ten  eerste  is  het  gezien  de  rekencapaciteit  van  de  huidige  generatie  pc's  goed 
mogelijk  de  gehele  schermopbouw  grafisch  te  doen.  Zodoende  kunnen  zowel  map 
als  tote  gelijktijdig  weergegeven  worden.  Daamaast  lijkt  het  interactie-principe 
van  directe  manipulatie  (zie  paragraaf  3.1)  de  beste  methode  om  het  AOW-systeem 
te  bedienen.  Deze  modeme  manier  van  systeembesturing  wordt  al  veelvuldig 
toegepast  (onder  andere  in  Microsoft  Windows)  zodat  het  mogelijk  is  dat  gebrui- 
kers  al  vertrouwd  zijn  met  deze  manier  van  werken.  Tegelijkertijd  kan  eventueel 
gebruik  worden  gemaakt  van  een  menuselectie-systeem  met  een  ondiepe  gelaagd- 
heid. 

In  alle  te  definieren  menu’s,  dialogen,  windows,  help-faciliteiten,  systeembood- 
schappen,  schermontwerp  en  kleurgebruik  moet  een  hoge  mate  van  consistentie 
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gehanteerd  worden.  Dit  komt  professioneel  over  en  bevordert  het  werkgemak  met 
de  gebmikersinterface.  Ten  aanzien  van  responstijden  en  schermsnelheid  moet 
gezorgd  worden  dat  de  gebruiker  direct  op  de  hoogte  gesteld  wordt  van  de  voort- 
gang  of  het  resultant  van  een  gekozen  actie,  om  duidelijkheid  te  scheppen  en  om 
ergemis  te  voorkomen.  Zodoende  weet  de  gebruiker  continu  waarmee  het  pro- 
gramma  bezig  is,  zelfs  al  zou  de  (eventueel  gekozen)  actie  enigszins  lang  duren. 

De  componenten  die  in  de  schermpresentatie  van  het  AOW-III  systeem  voorkomen 
zijn  de  volgende: 

Statusregel 

Een  statusregel  op  het  scherm  is  een  regel  waarop  on-line  informatie  aan  de  ge¬ 
bruiker  gegeven  kan  worden  over  de  huidige  status-quo  van  het  programma.  Zo 
kan  bijvoorbeeld  korte  hulp-informatie  aan  de  gebruiker  worden  gegeven  over  de 
huidige  gekozen  actie. 

Windows  &  pop-up  windows  (map/tote/orderoverzicht/clipboard) 

Een  window  is  een  afgebakend  gebied  op  het  scherm  waarin  informatie  getoond 
wordt  aan  de  gebruiker.  Deze  informatie  kan  in  het  AOW-systeem  bijvoorbeeld 
een  tote  of  een  map  zijn.  Een  speciale  window  is  het  clipboard. 

Objecten  die  de  gebruiker  geselecteerd  heeft  en  overgebracht  heeft  naar  het  clip¬ 
board  kunnen  ingezien  worden.  De  gegevens  worden  weergegeven  in  de  vorm  van 
een  tote. 

Pop-up  windows  zijn  windows  die  tijdens  de  uitvoering  van  het  programma  op  het 
scherm  kunnen  verschijnen  en  slechts  een  tijdelijk  karakter  hebben. 

Buttons/groepen 

Buttons  zijn  afgebakende  gebieden  op  het  scherm  in  de  vorm  van  knoppen  die  met 
behulp  van  de  muispijl  ingedrukt  kunnen  worden.  Hierbij  kunnen  de  knoppen 
optisch  lets  verzinken  in  het  scherm.  Na  het  indrukken  van  een  knop  wordt  veelal 
een  actie  opgestart  of  een  mode  ingesteld.  Buttons  zijn  geplaatst  in  groepen  met 
eenzelfde  type  functionaliteit.  Buttons  zijn  dus  bedoeld  voor  het  activeren  van  een 
actie  of  een  mode. 


4,2  Schematische  schermopbouw 

De  schermopbouw  zal  bestaan  uit  vier  functioned  gebieden:  zie  figuur  4.1  (zie 
ommezijde).  Hierin  is  ruimte  voor  een  gebied  die  een  map  en/of  een  tote  presen- 
teert,  een  gebied  voor  de  ordermodule,  een  gebied  voor  besturingsmenu's  en  een 
gebied  voor  korte  informatie  naar  de  gebruiker  toe.  De  vier  functioned  gebieden 
zijn  zodanig  op  het  scherm  geplaatst  dat  de  belangrijkste  gebieden  het  meest  in  het 
oog  springen.  Achtereenvolgens  worden  nu  de  vier  gebieden  behandeld 
(belangrijkste  eerst). 
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la,b.  Multi-functionele  windows 

Het  belangrijkste  (ofwel  het  meest  geraadpleegde)  gebied  is  het  gebied  dat  onder 
andere  de  tote  en/of  de  map  toont.  Dit  gebied  bestaat  uit  een  of  twee  windows  met 
aan  de  linkerzijde  een  rij  buttons  die  specifiek  zijn  voor  deze  window.  Een  eigen- 
schap  van  deze  windows  is  dat  ze,  indien  nodig^,  vergroot  kunnen  worden.  In  dit 
geval  krijgt  de  window  het  formaat  van  de  winTOws  la  en  lb  samen  zodat  nu 
bijvoorbeeld  een  map  in  zijn  geheel  kan  worden  afgebeeld.  De  twee  multi- 
functionele  windows  kunnen  meerdere  type  informatie  weergeven  hetgeen  ze 
uitermate  flexibel  in  gebruik  maken.  De  type  informatie  die  ze  kunnen  weergeven 
zijn  een  tote,  een  map,  een  order-overzicht  of  een  overzicht  van  geselecteerde 
objecten. 


Indeling  van  de  gebieden:  la,  b  Multi-functionele  window(s) 

2  Orderwindow 

3  Menu 

4  Extra  informatie 

Figuur4J:  Schematische  indeling  van  het  AOWdll  scherm. 

2,  Orderwindow 

De  orderwindow  bevat  de  ordermodule.  Vanuit  deze  window  kunnen  orders  aan 
het  systeem  gegeven  worden.  Ook  kan  in  deze  window  de  wijze  ingesteld  worden 
waarop  de  ordermodule  de  gebruiker  assisteert  bij  het  genereren  van  orders.  Ten 
eerste  kan  de  ordermodule,  indien  gewenst,  automatisch  orders  tonen  die  mogelijk 
zijn  met  de  geselecteerde  objecten.  Ten  tweede  kan  de  ordermodule  de  beschikbare 
orders  indelen  in  categorieen,  zoals  later  zichtbaar  is  in  paragraaf  4,3.4. 

3.  Menu 

De  bovenste  window  bevat  buttons  (knoppen)  voor  het  besturen  van  de  simulatie 
(alleen  voor  de  staff),  het  lezen  van  Email  en  bijvoorbeeld  voor  het  uitprinten  van 
een  tote.  Deze  window  heeft  een  algemeen  karakter  en  een  diversiteit  aan  functies 
en  wordt  daarom  bovenin  het  scherm  geplaatst. 
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4.  Extra  informatie 

Alle  extra  informatie  die  het  systeem  aan  de  gebruiker  kan  geven  wordt  verstrekt 
via  dit  window.  Zo  kan  via  deze  window  korte  on-line  informatie  gegeven  worden 
aan  de  gebruiker  over  bijvoorbeeld  de  huidige  status  quo  van  het  programma  of 
over  de  voortgang  van  bepaalde  processen. 


4.3  Uitvoering 

4.3.1  Hoofdscherm 

Na  het  opstarten  van  het  AOW-III  systeem  verschijnt  een  introductiescherm  van  het 
systeem.  Hierin  wordt  algemene  informatie  getoond  over  het  AOW-III  systeem  en 
moet  een  'eye-catcher'  zijn.  Daama  verschijnt  het  hoofdscherm:  zie  figuur  4.2. 


13  TNO-FEL  I99<i 


Airbase  Opera t 


Nargane  III 


Figuur  4.2:  Hoofdscherm  van  het  AOW-III  systeem  ( staff-station). 


In  bovenstaand  figuur  is  figuur  4. 1  direct  herkenbaar  die  een  schematische  indeling 
van  het  scherm  geeft.  Aan  de  linkerzijde  van  het  scherm  zijn  de  twee  multi- 
functionele  windows  herkenbaar  die  hier  een  map  en  een  tote  weergeven  (DCC 
MAP  en  WING  OPS  TOTE).  Aan  de  linkerzijde  van  deze  windows  zijn  buttons 
geplaatst  die  specifiek  voor  deze  window  gelden.  Rechts  van  de  beide  multi- 
functionele  windows  is  de  ordermodule  geplaatst  (ORDERS).  In  deze  window 
kunnen  orders  geselecteerd  worden  die  aan  het  AOW-III  simulatiesysteem  doorge- 
geven  kunnen  worden.  Boven  in  het  scherm  bevindt  zich  een  (passieve)  titelbalk 
met  direct  daaronder  een  rij  buttons  die  de  meest  algemene  en/of  hoofdfuncties 
bevatten  voor  het  gehele  systeem.  Daaronder  is  weer  een  informatie-balk  zichtbaar 
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met  de  meest  relevante  simulatie-informatie.  Aan  de  onderzijde  van  het  scherm  is 
een  regel  gereserveerd  waarmee  korte  informatie  aan  de  gebruiker  doorgegeven 
wordt.  In  de  komende  subparagrafen  worden  de  verscheidene  windows  uit  figuur 

4.2  uitgewerkt, 

4.3.2  De  besturingsbuttons  en  informatiebalk 

Het  bovenste  gedeelte  van  het  AOW-hoofdscherm  wordt  gebruikt  voor  de  bestu¬ 
ringsbuttons  van  het  AOW-systeem;  het  onderste  gedeelte  voor  een  informatiebalk 
waarmee  korte,  relevante  informatie  aan  de  gebruiker  wordt  gegeven  over 
(bijvoorbeeld)  de  huidige  actie.  Figuur  4.3  toont  beide. 


base  Oper-at  ions  Wargane  III  —  KMA — 


£3l]  I N  i  ►»  I  ►  i  ►►  i  II  i  B I 


Alarm  status  |  NO  ALERT 


Ground  raid  warning  fUHITE  Air  raid  warning  j  UHITE  Air  attack  \  NO 


j  Pr ess  button  to  select  map.^tote/'Clipboard/'orders/mail.  AOU  |  BLOCKED  Speed  |  8  Time  |  OO/'OOiOO 


Figuur  4.3:  De  besturingsbuttons  (boven)  en  de  informatiebalk  ( onder). 


7.  Besturingsbuttons 

De  besturingsbuttons  zijn  ingedeeld  in  drie  groepen  voor  zowel  het  staff-  als  het 
spelersstation.  Daamaast  bevat  het  bovenste  gedeelte  ook  nog  informatie  over  de 
hoeveelheid  mail  die  naar  het  station  verstuurd  is.  Hieronder  worden  de  vier  groe¬ 
pen  van  links  naar  rechts  uitgewerkt: 


Figuur  4.4:  Mail  informatie. 

Dit  geeft  het  aantal  ontvangen  boodschappen  weer.  In  de  vorm  van  een  tote  (zie 
figuur  4.17)  kan  de  ontvangen  mail  gelezen  worden.  Indien  er  mail  ontvangen  is  die 
nog  niet  gelezen  is  dan  wordt  het  getal  rood  weergegeven.  Indien  alle  mail  al  gele¬ 
zen  is  dan  wordt  het  getal  zwart  weergegeven. 
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Staff  version 

User  version 


Figuur  4.5:  De  besturingsbuttons  van  het  staff-  en  het  userstation. 


Het  staff-station  heeft  de  beschikking  over  de  voor  het  staff-station  van  belang 
zijnde  buttons,  zoals  tools  (links)  en  motion  (midden).  Met  behulp  van  de  button 
met  dcfloppydisc  erop  kan  het  staff-station  een  exercise  laden  (zie  paragrafen  6.3.4 
en  7.4)  of  spelerorders  laden.  De  derde  button  {sleutel)  is  voor  het  instellen  van  de 
simulatiesnelheid  en  de  universe-update  frequentie.  De  middelste  serie  buttons  is 
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voor  het  spelen,  pauseren,  skippen  en  stoppen  van  de  simulatie.  De  meest  rechter 
button  is  voor  het  aktiveren  van  de  slowrun-optie  op  het  simulatie-station. 

Het  user-station  heeft  in  het  midden  de  beschikking  over  vier  voorkeurinstellingen 
voor  het  scherm,  waarmee  een  bepaalde  opzet  (tote,  map,  tote&map,  tote&orders, 
enz)  kan  worden  opgeslagen  met  behulp  van  de  button  met  defloppydisc, 

De  gemeenschappelijke  buttons  zijn  de  printer  (uiterst  links)  voor  het  uitprinten 
van  een  lijst  of  een  map  en  de  noodrem  (uiterst  rechts)  voor  het  tijdelijk  laten 
verlopen  van  de  simulatiesnelheid  op  1:1  (voor  de  tijdsduur  van  drie  minuten). 

2.  Relevante  simulatie-informatie 

Direct  onder  de  drie  groepen  buttons  zijn  een  aantal  velden  zichtbaar  met  de  meest 
relevante  alarm-informatie. 

3.  Informatiebalk 

De  informatiebalk  onderaan  het  scherm  toont  directe  hulp-informatie  over  de 
huidige  positie  van  de  muispijl.  Indien  de  muispijl  zich  bijvoorbeeld  op  de  zoom- 
button  van  de  map  bevindt  dan  zal  als  voorbeeld  de  melding  Click  left  mousebutton 
to  zoom  on  map  gegeven  worden.  Tenslotte  wordt  de  huidige  simulatie-status,  tijd 
en  speelsnelheid  getoond. 

4.3.3  De  multi-functionele  window 

De  multi-functionele  window,  waarvan  in  figuur  4.2  twee  actief  zijn,  kan  in  totaal 
vier  type  informatie  weergeven,  te  weten  een  map,  een  tote,  een  overzicht  van 
gegeven  orders  aan  het  systeem  en  de  mail.  De  gebruiker  kan  zelf  bepalen  welke 
informatie  door  welke  window  wordt  weergegeven:  zo  is  het  dus  ook  mogelijk 
tegelijkertijd  twee  totes  of  twee  maps  weer  te  geven.  Ook  kan  een  window  vergroot 
worden  zodat  in  totaal  een  window  zichtbaar  is  (zie  figuur  4.19).  Aan  de  linkerzijde 
van  de  window  is  een  rij  buttons  zichtbaar  waarmee  met  de  bovenste  button  (die 
apart  staat  van  de  overige)  de  type  informatie  gekozen  kan  worden  (zie  figuur  4.6). 


■j 

Ell ! 

&\ 

Figuur  4.6:  Select-buttons  voor  de  window-functie  ( van  links  naar  rechts  de  functies 
map,  tote,  order  en  mail-overzicht). 


Overeenkomstig  wordt  de  gekozen  button  linksboven  getoond  in  de  window. 
Afhankelijk  van  de  gekozen  window  verschijnen  dan  de  relevante  buttons  voor  de 
betreffende  window.  Indien  een  map  of  een  tote  gekozen  is  dan  kan  met  de  boven¬ 
ste  button  van  de  rij  relevante  buttons  de  type  map  of  tote  bepaald  worden.  De 
overige  buttons  hebben  een  meer  specifieke  functie.  Zie  de  figuren  4.7  tot  en  met 
4.18  voor  de  layout  van  de  vier  mogelijke  keuzes. 
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Figuur  4. 7:  De  multi-functionele  window  als  map. 


1,  De  multi-functionele  window  als  map 

In  figuur  4.7  is  een  map  gedeeltelijk  zichtbaar.  Aan  de  hand  van  de  twee  buttons 
aan  de  rechter-  en  onderzijde  in  de  window  kan  het  zichtsveld  verplaatst  worden: 
dit  zijn  de  zogenaamde  scroll-buttons.  Bij  de  map  zijn  nu  aan  de  linkerzijde  van  de 
window  vier  buttons  beschikbaar.  Bij  de  onderste  drie  buttons  zijn  thans  een  buil¬ 
ding,  een  vergrootglas  en  een  grid  zichtbaar.  Indien  de  building  met  de  muis  gese- 
lecteerd  wordt  dan  verschijnt  rechts  naast  de  buttons  een  nieuwe  groep  waaruit  een 
nieuw  type  map  gekozen  kan  worden.  Met  behulp  van  het  vergrootglas  kan  op  de 
map  in-  of  uitgezoomd  worden  en  met  behulp  van  de  grid-button  kan  een  grid  over 
de  map  geplaatst  worden.  Uitwerking  van  de  diverse  buttons: 

-  Map-keuze 


Figuur  4. 8:  Map  keuzes  ( staff-versie). 


Met  deze  (meest  linkse)  button  kan  de  map  gekozen  worden.  Wanneer  deze  button 
wordt  ingedrukt  dan  verschijnen  direct  rechts  van  de  button  een  viertal  nieuwe 
buttons  waaruit  de  type  map  gekozen  kan  worden  (merk  op  dat  de  rechtse  button 
hiervan  de  huidige  geselecteerde  map  is).  De  te  kiezen  maps  zijn  achtereenvolgens 
de  building-map,  runway-map,  DCC-map  en  DCC-map  (staff  versie). 


-  Zoom-keuze 


FIT 


HEJ 


Figuur  4.9:  Zoom  keuzes. 

Na  het  indrukken  van  de  meest  linkse  button  verschijnen  drie  nieuwe  buttons  voor 
respectievelijk  (van  links  naar  rechts)  het  inzoomen  op  de  map  en  de  twee  opties 
1:1  enfit.  De  optie  1:1  zorgt  ervoor  dat  de  gehele  map  in  de  default  zoom-instelling 
komt;  de  optie  fit  zorgt  ervoor  dat  de  map  exact  in  de  beschikbare  window-ruimte 
past.  Daamaast  beschikt  een  map  over  een  button  (zie  figuur  4.7  rechtsboven). 
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Zolang  de  ‘+’  button  wordt  ingedrukt  wordt  continu  ingezoomd  op  de  map;  bij  de  *- 
’  button  wordt  continu  uitgezoomd. 

-  Grid-keuze 


X|#i 

p! 

CJ 

EJ 

£ 

£ 

Pj 

Figuur  4. 1 0:  Grid  keuzes. 

Deze  button  zorgt  ervoor  dat  er  een  grid  over  de  map  geplaatst  kan  worden.  De 
volgende  acht  keuzes  staan  ter  beschikking: 


label  4. 1 :  Grid  keuzes 


Grid  button 

Functie 

X 

Clear  grid  (remove  grid) 

# 

Grid  references 

D 

Defence  grid 

C 

Communications-failure  grid 

E 

Power-failure  grid 

N" 

NBC  condition  grid 

N*" 

NBC  operations  grid 

P 

Patrol  activity  grid 

2.  De  multi-functionele  window  als  tote 

Net  als  bij  de  map  kan  bij  de  tote  de  type  tote  gekozen  worden  aan  de  hand  van  de 
tweede  button  aan  de  linkerzijde  in  de  window.  Indien  deze  button  geselecteerd 
wordt  dan  verschijnt  rechts  van  deze  button  een  nieuwe  groep  buttons  waaruit  de 
nieuwe  tote  gekozen  kan  worden.  Voorts  bevindt  zich  in  de  window  aan  de  rechter- 
zijde  een  scroll-button  waarmee  door  de  tote  gescrolled  kan  worden. 


Figuur  4.11:  De  multi-functionele  window  als  tote. 

Voorts  kunnen  regels  (objecten)  uit  de  tote  geselecteerd  worden.  Een  regel  wordt 
geselecteerd  door  de  muispijl  op  een  regel  te  plaatsen  en  de  blauwe  balk  erop  te 
plaatsen.  Wanneer  nu  nogmaals  op  de  muisknop  gedrukt  wordt  dan  wordt  de  regel 
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geselecteerd  en  krijgt  de  kleur  geel.  De  gebruiker  kan  de  muisknop  ook  ingedrukt 
houden  en  zodoende  een  aantal  tote-regels  tegelijkertijd  selecteren.  Met  behulp  van 
de  geselecteerde  regels  (objecten)  kan  nu  een  order  gegeven  worden  of  kunnen  de 
objecten  naar  het  clipboard  gekopieerd  worden. 

Uitwerking  van  de  button: 


Figuur  4.12:  Tote  keuzes. 

Na  het  kiezen  van  de  tote-button  zal  in  eerste  instantie  alleen  de  bovenste  rij  but¬ 
tons  verschijnen:  dit  zijn  de  categorieen  mission-tote,  personnel-tote,  equipment- 
tote,  disturbance-tote,  airbase-status  tote  en  building  tote.  Nadat  hieruit  een  keuze  is 
gemaakt  dan  verschijnt  (eventueel)  onder  deze  button  een  nieuwe  rij  buttons  waar- 
uit  de  definitieve  tote  gekozen  kan  worden. 

5.  De  multUfunctionele  window  als  order-overzicht 

De  derde  type  window  geeft  een  overzicht  van  gegeven  orders.  De  in  figuur  4.13 
afgebeelde  window  geeft  voor  het  staff-station  een  overzicht  van  alle  staff-orders. 
Wederom  aan  de  linkerzijde  van  de  window  bevinden  zich  een  drietal  buttons  die 
specifiek  zijn  voor  de  orderwindow. 

Met  de  bovenste  button  uit  deze  groep  kan  een  geselecteerde  order  gecancelled 
worden  indien  de  order  waiting  is  (zie  ook  de  uitwerking  van  de  buttons).  Met  de 
tweede  button  kunnen  geselecteerde  orders  verwijderd  worden.  Met  de  derde 
button  kunnen  spelers  specifiek  geselecteerd  worden  waarvan  de  orders  worden 
weergegeven.  Een  geselecteerde  order  wordt  in  de  kleur  geel  weergegeven  in  de 
tote.  De  wijze  waarop  orders  geselecteerd  kunnen  worden  is  in  paragraaf  3.3  be- 
schreven. 
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Figuur4,13:  De  multi-functionele  window  als  order-overzicht 


Uitwerking  van  de  buttons: 


-  Cancel  order 


Figuur  4. 14:  Cancel  order  button. 

Orders  die  niet  uitgevoerd  kunnen  worden  omdat  bijvoorbeeld  een  resource  tijdelijk 
buiten  gebruik  is  krijgen  de  status  waiting.  Deze  waiting  orders  kunnen  cancelled 
worden  zodat  ze  niet  meer  uitgevoerd  kunnen  worden. 

-  Delete  order 


£j 

Figuur  4. 15:  Delete  order  button. 

Geselecteerde  orders  kunnen  verwijderd  worden  uit  het  systeem,  mits  deze  nog  niet 
zijn  uitgevoerd. 

-  Select  user  (staff-only) 


userI 

USERS 

USER  I  user!  USER  1 

user! 

USER! 

USER  I  user! 

user! 

_2J 

_7J 

S  1 

UJ 

Figuur  4.16:  Select  user  buttons. 

Het  staff-station  heeft  de  mogelijkheid  de  orders  van  de  spelerstations  in  te  zien. 
Met  behulp  van  deze  button  kan  de  staff  selecteren  van  welke  gebruikers  hij  de 
orders  wil  inzien. 
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4.  De  multi-functionele  window  als  mail-overzicht 

De  vierde  type  window  toont  de  ontvangen  mail.  Figuur  4.17  toont  de  layout  van  dit 
window.  Met  behulp  van  de  delete-button  in  de  window  kunnen  mails  uit  de  lijst 
verwijderd  worden. 


Figuur  4.17:  De  multi-functionele  window  als  mail-overzicht. 


Uitwerking  van  de  button: 
-  Delete  selected  mail 


m 

Figuur  4.18:  Delete  selected  mail  button. 

Met  behulp  van  deze  button  kunnen  geselecteerde  mailberichten  uit  de  lijst  verwij¬ 
derd  worden. 

Tenslotte  is  het  mogelijk  om  een  window  te  vergroten:  hiertoe  dient  de  button  die 
rechtsboven  is  geplaatst.  Indien  de  window  vergroot  wordt  dan  beslaat  hij  in  totaal 
twee  windows  en  krijgt  de  window  het  formaat  zoals  is  weergegeven  in  figuur  4.19. 
Qua  functionaliteit  blijft  de  window  in  dit  formaat  gehjk  aan  het  kleine  formaat,  zij 
het  dat  de  window  nu  meer  informatie  kan  tonen.  Door  wederom  de  button  rechts¬ 
boven  te  gebruiken  krijgt  de  window  zijn  oorspronkelijke  formaat  terug.  Daamaast 
bevinden  zich  twee  scroll-buttons  in  de  map  waarmee  het  zichtveld  over  de  map 
verplaatst  kan  worden. 
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Figuur  4.19:  Hetformaat  van  een  grote  (map)window. 


4.3.4  De  order-window 

Met  behulp  van  de  orderwindow,  rechts  geplaatst  op  het  AOW-scherm  naast  de 
multi-functionele  windows,  kunnen  orders  aan  het  AOW-systeem  worden  gegeven. 
Figuur  4.20  toont  deze  window.  De  window  bestaat  globaal  uit  vier  delen,  te  weten 
(van  boven  naar  beneden)  de  gekozen  ordemaam,  de  ‘Enter  Order  ^-button,  een 
overzicht  van  automatisch  geselecteerde  orders  en  een  overzicht  van  alle  orders.  De 
bedieningswijze  is  dat  de  gebruiker  een  order  kiest  uit  een  van  de  twee  windows  en 
vervolgens  met  ‘Enter  Order’  de  order  kan  editten.  De  editvelden  worden  over  de 
ordermodule  (figuur  4.20)  geplaatst. 
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ORDERS 

_ Ordernawe 

I  ftCTIWTE  OBJECT 


&  Enter  Order! 


Selected  Orders 


Figuur  4.20:  De  orderwindow  voor  het  geven  van  orders. 


4.3.5  Database-update  tijdens  simulatie 

Bij  het  AOW-II  systeem  werd  tijdens  een  database-update  een  rode  window  over 
het  scherm  geplaatst  waarin  vemield  werd  dat  een  nieuwe  database  ingelezen  werd. 
Bij  het  AOW-III  systeem  wordt  nu  afgezien  van  deze  rode  window  daar  deze  het 
scherm  gedeeltelijk  afdekt  en  op  den  duur  afleidend  gaat  werken.  Bij  het  AOW-III 
systeem  wordt  gekozen  voor  een  muispijl  die  verandert  in  een  zandloper  (deze  is  te 
zien  in  figuur  4.2  in  de  map).  Daamaast  is  rechtsonder  in  het  scherm  een  statusbalk 
te  zien  die  de  gebruiker  exact  informeert  over  de  voortgang  van  de  database-update. 
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5.  Interne  functionaliteit 


Er  zijn  een  aantal  eigenschappen  die  thans  nog  aan  het  AOW-II  systeem  toege- 
voegd  of  aangevuld  moeten  worden  voor  het  AOW-III  systeem.  Dit  hoofdstuk 
geeft  een  overzicht  van  al  die  aspecten. 

Er  zijn  een  drietal  punten  die  aan  het  AOW-systeem  aangepast  moeten  worden,  te 
weten: 

L  Aanpassen  van  de  werkdruk  van  de  spelers 

Een  aantal  taken  zouden  geautomatiseerd  of  gedeautomatiseerd  moeten  worden, 
afhankelijk  van  de  werkdruk  van  een  willekeurige  speler. 

2.  Discretiseren  van  processen 

De  behoefte  bestaat  om  processen  (taken)  te  kunnen  afbreken.  Vooral  langdurende 
taken  kunnen,  wanneer  ze  eenmaal  zijn  opgestart,  niet  meer  worden  afgebroken  als 
daartoe  de  behoefte  zou  bestaan. 

3.  Remote  orders  op  het  staff-station 

Het  staff-station  moet  de  mogelijkheid  hebben  orders  van  spelers  te  wijzigen  om 
de  voortgang  van  de  AOW-sessie  te  kunnen  waarborgen.  Dit  aspect  van  het  staff- 
station  wordt  remote-orders  genoemd.  Hiermee  heeft  het  staff-station  toegang  tot 
alle  in  het  systeem  aanwezige  (gegeven)  orders  (verleden,  heden  en  toekomst)  en 
de  mogelijkheid  om  de  orders  te  wijzigen  of  te  verwijderen.  Dit  biedt  daardoor  de 
mogelijkheid  om  foutief  gegeven  orders  te  wijzigen  of  te  verwijderen. 
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6.  Introductie  AOW-III  tools 


In  dit  hoofdstuk  wordt  een  opsomming  gegeven  van  alle  functionaliteiten  die  in  de 
AO W- tools  tot  uiting  dienen  te  komen.  Op  basis  van  deze  opsomming  worden  de 
onderwerpen  stapsgewijs  uitgewerkt  in  de  hiema  volgende  hoofdstukken. 

Onder  de  tools  worden  verstaan  de  uitbreidingen  voor  het  AOW-III  systeem  die  los 
staan  van  het  AOW-III  systeem  zelf.  Het  betreft  hier  een  apart,  losstaand  pro- 
gramma  waarmee  onder  andere  vliegbases  ontworpen  kunnen  worden  ter  voorbe- 
reiding  van  AOW-sessies. 


Er  kunnen  twee  categorieen  hulpmiddelen  worden  onderscheiden,  zie  figuur  6.1: 


(1)  Static  (2)  Scenario 


Draaiboek 

Oefening 

Commando 

Structuur 

Figuur  6.1:  Overzicht  van  de  diverse  hulpmiddelen. 

Een  overzicht  van  te  ontwikkelen  tools: 

•  Static:  ontwerpen  van  vliegbases  (ontwerp  van  infrastructuur,  organ isatiestruc- 
tuur,  beschikbare  resources,  processen); 

•  Ontwerpen  van  scenario's; 


6.1  Ontwerpen  van  vliegbases 

Voor  een  flexibele  inzet  van  het  AOW-systeem  zal  een  airbase-designer  ontworpen 
worden  waarmee  een  vliegbasis  kan  worden  ingevoerd.  Deze  kan  vervolgens  door 
het  AOW-systeem  ingelezen  worden  zodat  met  een  nieuwe  vliegbasis  een  AOW- 
sessie  gespeeld  kan  worden.  Bij  het  ontwerpen  van  vliegbases  worden  de  volgende 
aspecten  ingevoerd: 
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•  Infrastructuur  van  de  vliegbasis; 

(aanwezige  gebouwen,  start-  en  rolbanen,  faciliteiten  zoals  communicatie  en 
stroom) 

•  Organisatiestructuur  van  de  vliegbasis; 

(beschikbare  aantallen  en  soorten  personeel) 

•  Materieel; 

(beschikbare  voorraden  supplies,  transportmiddelen,  vliegtuigen,  luchtverdedi- 
gingssystemen) 

•  Processen; 

(tijdsduren  van  de  verschillende  activiteiten  en  eventuele  vertragingsfactoren 
bv.  als  gevolg  van  het  ontbreken  van  communicatielijnen). 

Zodoende  is  het  in  principe  zelfs  mogelijk  om  voor  elke  vliegbasis  apart  een  data¬ 
base  te  genereren  met  daarin  alle  aspecten  en  details  van  de  vliegbasis  zodat  speci- 
fiek  met  een  bepaalde  vliegbasis  geoefend  kan  worden.  Uiteraard  kunnen  ook  Out- 
of-Area  vliegbases  ontworpen  worden  met  deze  tool. 


6,2  Ontwerpen  van  scenario’s 

Naast  het  ontwerpen  van  vliegbases  kunnen  ook  scenario's  ontworpen  worden. 
Hierbij  worden  de  volgende  aspecten  ingevoerd: 

•  Draaiboek. 

In  een  draaiboek  wordt  aangegeven  wat  op  bepaalde  tijdstippen  op  een  vliegba¬ 
sis  gebeurt,  zoals  een  aanval  van  vijandelijke  vliegtuigen  op  tijdstip  X;  het  be- 
treft  in  feite  dus  een  logboek  van  (toekomstige)  gebeurtenissen  op  een  vliegba¬ 
sis  oftewel  verstoringen  van  buiten  af  waar  de  speler  geen  invloed  op  heeft. 
Door  diverse  draaiboeken  te  ontwerpen  kunnen  met  het  AOW-systeem  diverse 
situatie's  geoefend  worden. 

•  Managementsstructuren  op  de  vliegbasis. 

Dit  betreft  de  definitie  van  de  spelstructuur:  hoeveel  spelers  worden  onder- 
scheiden,  wat  zijn  hun  namen  en  wat  zijn  hun  bevoegdheden  (dat  wil  zeggen  de 
beschikbare  informatie  en  orders). 


63  Inventarisatie  editors 

6.3.1  Inleiding 

Zoals  eerder  werd  vermeld  vallen  de  tools  uiteen  in  een  aantal  categorieen  (zie 
tabel  6.1).  Met  de  tools,  die  geintegreerd  zullen  worden  in  een  programma,  is  het 
mogelijk  om  geheel  naar  eigen  inzichten  en  wensen  vliegbases  en  scenario’s  te 
ontwerpen.  In  de  tools  worden  de  volgende  functionaliteiten  geboden: 
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Tabel  6J:  Overzicht  van  de  functionaliteiten  van  de  tools. 


Deel 

Categorie 

Functionaliteit 

Toelichting 

Static 

Airbase 

Infrastructuur 

Organisatie 

Resources 

Definitie  van  de  gebouwen,  start-en 
landingsbanen,  taxiways. 

Definitie  van  aantallen  personeel  op  de 
vliegbasis. 

Definitie  van  de  vliegtuigen,  LVD- 
systemen,  supplies  en  transportmid- 
delen. 

Processen 

Processen 

Tijdsduur  en  vertragingsfactoren. 

Scenario 

Spelers 

Spelerssetup 

Autorisatie 

Definitie  van  de  spelers. 

Autorisaties  van  user-interface  scher- 
men,  orders,  mail. 

Objecten 

Autorisatie 

Autorisatie  van  objecten. 

Orders 

Draaiboek  oefening 

Tasking  door  CAOC,  wing  ops  of  KLu 
staf;  vijandelijke  lucht/grondaanval  met 
verstoringen;  beschikbare  versterkin- 
gen. 

Exercise 

Exercise 

Exercise  manager 

Bewaart  een  vliegbasis,  scenario  en 
autorisatie  als  4en  geheel  zodat  het 
AOW-III  systeem  dit  als  e^n  geheel 
kan  inlezen. 

6.3.2  Static  editor 

De  static  editor  wordt  toegepast  voor  het  ontwerpen  van  een  nieuwe  of  het  aanpas- 
sen  van  een  bestaande  vliegbasis.  De  editor  zal  een  user- interface  krijgen  welke 
vergelijkbaar  is  met  die  van  het  AOW-III  systeem  zodat  de  gebruikers  (IDL  do- 
centen  en  TNO-FEL  begeleiders)  relatief  snel  vertrouwd  zullen  geraken  met  de 
omgang  en  de  bediening  van  het  systeem. 

6.3.3  Scenario  editor 

De  scenario  editor  wordt  toegepast  voor  het  ontwerpen  van  een  draaiboek  voor  een 
spelsessie,  alsmede  voor  het  defmieren  van  de  commandostructuur  (in  het  alge- 
meen  de  autorisatie  van  totes,  maps,  orders,  object  autorisatie  en  de  spelersstruc- 
tuur).  Voor  het  invoeren  van  het  draaiboek  is  de  bestaande  methodiek  van  orders 
invoeren  bruikbaar. 

6.3.4  Exercise  manager 

Aangezien  een  aantal  files  van  elkaar  afhankelijk  zijn  is  het  noodzakelijk  een 
bepaalde  volgorde  te  hanteren  bij  het  creeren  van  de  files.  Zo  is  het  bijvoorbeeld 
noodzakelijk  om  eerst  een  infrastructuur  te  ontwerpen,  hetgeen  de  basis  vormt  van 
de  vliegbasis,  en  dan  pas  een  organisatie  en  de  resources  te  defmieren.  De  exerci¬ 
se-manager  zal  de  gebruiker  sturen  in  de  volgorde  waarin  de  onderdelen  ontwor- 
pen  moeten  worden.  Voorts  zorgt  de  exercise-manager  ervoor  dat  de  gehele  vlieg¬ 
basis,  inclusief  het  scenario,  onder  een  naam  bewaard  kan  worden  zodat  de  gebrui¬ 
ker  op  het  staf-station  de  gehele  situatie  aan  de  hand  van  slechts  een  naam  kan 
laden.  De  naam  wordt  dan  intern  geassocieerd  met  de  diverse  andere  files. 


TNO-rapport 


FEL-96-A284 


36 


6.4  Totaaloverzicht 

Figuur  6.1  toont  het  totaaloverzicht  van  de  AOW-tools  met  het  complete  AOW-III 
systeem.  Hiemit  blijkt  dat  de  tools  los  staan  van  het  AOW-III  systeem  en  dus  apart 
gebruikt  kan  worden.  Indien  eenmaal  de  exercise  is  gedefinieerd  aan  de  hand  van 
de  tools  dan  kan  deze  in  het  AOW-III  systeem  ingelezen  worden  aan  de  hand  van 
het  staf-station. 


Figuur  6.1:  Samenhang  tussen  de  tools  en  het  AOW-III  systeem. 
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7.  Tool  editors 

7,1  Inleiding 

Dit  hoofdstuk  gaat  stapsgewijs  alle  functies  van  de  drie  editors  na  en  presenteert 
deze  afzonderlijk  met  inbegrip  van  invoer  en  uitvoer.  Er  wordt  gekeken  naar  het 
user-interface  ontwerp,  overeenkomsten  en  verschillen  tussen  de  functies  en  de 
eventuele  impact  op  het  AOW-III  systeem  (filemanagement).  Achtereenvolgens 
worden  de  static-editor,  de  scenario-editor  en  de  exercise-manager  behandeld. 


7.2  Static  editor 


7.2.1  Functionaliteiten 

Resumerend  kan  de  static  editor,  naar  aanleiding  van  hoofdstuk  zes  en  de  probleem 
analyse,  worden  onderverdeeld  in  vier  typen  invoer: 


Infrastructuur:  Buildings  (BD),  te  weten  gebouwen,  runway’s  en  taxiways; 
Organisatie:  Personeel  (PS); 

Resources:  Aircraft  (AC),  airdefence  (AD),  supplies  (SU)  en  transport 

(TR); 

Procestijden  en  vertragingsfactoren  (staat  op  zich  los  van  de 
infrastructuur  maar  wordt  wel  tot  static  gerekend). 


1. 

2. 

3. 


4.  Processen: 


ad  1:  Infrastructuur 

Tot  de  objecten  die  tot  de  infrastructuur  van  een  vliegbasis  behoren  zijn 

alleen  de  gebouwen,  runways  en  taxiways.  Deze  zijn  in  AOW  ondergebracht 

onder  het  type  building  (BD).  De  acties  die  bij  de  creatie  van  de  infrastruc¬ 
tuur  kunnen  plaatsvinden  zijn: 

a.  Keuze  uit  de  diverse  gebouwen,  runway  en  taxiway; 

b.  Saven  van  de  infrastructuur; 

c.  Laden  van  een  infrastructuur; 

d.  Clearen  van  de  infrastructuur; 

e.  Wanneer  een  nieuw  object  (BD)  gecreeerd  wordt  moeten  een  aantal 
specifieke  gegevens  direct  aangepast  kunnen  worden; 

f.  Een  lijst  van  alle  aanwezige  (gecreeerde)  objecten  op  de  vliegbasis. 
Indien  hieruit  een  object  gekozen  wordt  dan  is  op  de  map  direct  zicht- 
baar  waar  deze  zich  bevindt  (aan  de  hand  van  een  rode  cirkel)  en  kun¬ 
nen  de  gegevens  direct  in  de  editfields  aangepast  worden; 

g.  Het  verwijderen  van  een  object. 


Onderstaande  tabel  geeft  aan  welke  gegevens  van  belang  zijn  voor  het  defmieren 
van  de  objecten  (van  belang  bij  punt  e): 
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Tabel  7.1:  Parameters  voor  het  type  building  ( BD). 


Gebouwen: 

Soort  (naam/functie); 

Type  (mate  van  bescherming  (open,  sheltered,  hardened,  filtered)); 
Locatie  (in  x,y  coordinaten  of  aanwijzen  op  de  kaart); 

Beschikbare  ruimte; 

Cluster. 


Taxiways;  Start-  en  landingsbanen: 

Lengte; 

Locatie; 

Cluster; 

Type  (mate  van  bescherming  (open,  sheltered,  hardened,  filtered)). 


ad  2:  Organisatie 

Bij  het  personeel  is  het  van  belang  waar  en  hoeveel  personeel  er  beschikbaar 
is.  Voor  wat  betreft  de  parameters  wordt  er  geen  onderscheid  gemaakt  in 
verschillende  type  personeel  (zoals  wel  het  gevai  bij  het  type  building,  zie 
tabel  7.2).  De  acties  die  bij  de  creatie  van  de  organisatie  (PS)  kunnen  plaats- 
vinden  zijn: 

a.  Keuze  uit  de  diverse  personeelstypes; 

b.  Saven  van  een  organisatie; 

c.  Laden  van  een  organisatie; 

d.  Clearen  van  een  organisatie; 

f.  Wanneer  een  nieuw  object  (PS)  gecreeerd  wordt  moeten  een  aantal 
specifieke  gegevens  direct  aangepast  kunnen  worden; 

g.  Een  lijst  van  alle  aanwezige  (gecreeerde)  objecten  op  de  vliegbasis. 
Indien  hieruit  een  object  gekozen  wordt  dan  is  op  de  map  direct  zicht- 
baar  waar  deze  zich  bevindt  (aan  de  hand  van  een  rode  cirkel)  en  kun¬ 
nen  de  gegevens  direct  in  de  editfields  aangepast  worden; 

h.  Het  verwijderen  van  een  object. 

NB:  Een  organisatie  is  gekoppeld  aan  een  bepaalde  infrastructuur  en  kan 
niet  gekoppeld  worden  aan  andere,  afwijkende,  infrastructuren. 

Onderstaande  tabel  geeft  de  benodigde  parameters  (van  belang  bij  punt  f): 
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Tabel  72:  Parameters  voor  het  type  personeel  (PS). 


Personeel: 

Categorie; 

Aanta!  teams; 

Aantal  mensen  per  team  (*); 

Shiftnummer  per  team; 

Groepsnummer  per  team; 

Lastgevingen  per  team  (1e,  2e,  3e  taken); 
Locatie  per  team  (gebouw); 

Benodigde  ruimte  in  gebouwen  (*). _ 


Uitgangspunt:  vaste  lijst  van  categorieen  personeel.  Sommige  kenmerken  van  het 
personeel  worden  vooraf  gedefinieerd,  zoals  (*).  Hiermee  samen  hangt  de  defmitie 
van  de  werktijden  van  de  diverse  shifts,  d.w.z.  begintijd  en  duur. 

ad  3:  Resources 

Het  type  resource  (materieel)  is  diverser  dan  de  voorgaande  punten  en 

bestaat  uit  vier  types:  vliegtuigen  (AC),  luchtverdedigingssystemen  (AD), 

supplies  (SU)  en  transportmiddelen  (TR).  De  acties  die  bij  de  creatie  van  re¬ 
sources  (AC,  AD,  SU,  TR)  kunnen  plaatsvinden  zijn: 

a.  Keuze  uit  de  type  resource  (AC,  AD,  SU  of  TR).  Afhankelijk  van  wat 
wordt  gekozen  zal  een  overzicht  getoond  worden  van  de  keuzemoge- 
lijkheden. 

b.  Keuze  uit  de  diverse  soorten  (van  AC,  AD,  SU  dan  wel  TR); 

c.  Saven  van  resources; 

d.  Laden  van  resources; 

e.  Clearen  van  resources; 

f.  Wanneer  een  nieuw  object  (AC,  AD,  SU  of  TR)  gecreeerd  wordt 
moeten  een  aantal  specifieke  gegevens  direct  aangepast  kunnen  wor¬ 
den; 

g.  Een  lijst  van  alle  aanwezige  (gecreeerde)  objecten  op  de  vliegbasis. 
Indien  hieruit  een  object  gekozen  wordt  dan  is  op  de  map  direct  zicht- 
baar  waar  deze  zich  bevindt  (aan  de  hand,  van  een  rode  cirkel)  en 
kunnen  de  gegevens  direct  in  de  editfields  aangepast  worden. 
Resources  zijn,  evenals  een  organisatie  dat  is,  gekoppeld  aan  een  be- 
paalde  infrastructuur  en  kan  niet  gekoppeld  worden  aan  andere,  af- 
wijkende,  infrastructuren; 

h.  Het  verwijderen  van  een  object. 

Onderstaande  tabel  geeft  de  benodigde  parameters  (van  belang  bij  punt  f): 
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Tabel  7.3:  Parameters  voor  de  types  aircraft  (AC),  airdefence  (AD),  supplies  (SU)  en 
transport  (TR). 


Vliegtuigen: 

Soort  (naam); 

Aantal; 

Initiele  configuratie  per  vliegtuig  (wapen  en  brandstof); 
Capabilities  per  vliegtuig  (AWX); 

Locatie  per  vliegtuig  (gebouw) 

Benodigde  ruimte  in  gebouwen  (*); 

Mate  van  bescherming  (open,  sheltered,  hardened,  filtered)  (*). 

Luchtverdedigingssystemen: 

Soort  (naam); 

Aantal; 

Locatie  persysteem  (gebouw); 

Benodigde  ruimte  in  gebouwen  (*); 

Mate  van  bescherming  (open,  sheltered,  hardened,  filtered)  (*). 

Supplies: 

Soort  (naam); 

Aantal  (geassembleerd  en  ongeassembleerd); 

Locatie  per  supply  eenheid  (gebouw); 

Benodigde  ruimte  in  gebouwen  (*); 

Mate  van  bescherming  (open,  sheltered,  hardened,  filtered)  (*). 

Transportmiddelen: 

Soort  (naam); 

Aantal; 

Transportcapaciteit  (*); 

Verplaatsingssnelheid  (*); 

Locatie  per  transportmiddel  (gebouw) 

Benodigde  ruimte  in  gebouwen  (*); 

Mate  van  bescherming  (open,  sheltered,  hardened,  filtered)  (*). 


Uitgangspunt:  vaste  lijst  van  soorten  middelen.  De  mogelijkheid  bestaat  dat  een 
aantal  kenmerken  vooraf  is  gedefinieerd,  zoals  (*). 

ad  4:  Processen 

Bij  de  processen  kunnen  de  procestijden  en  de  vertragingsfactoren  (zoals  bij 
het  opereren  onder  NBC-condities)  aangepast  worden.  Dit  is  een  lijst  met 
getallen  die  aangepast  kunnen  worden.  De  acties  die  bij  het  aanpassen  van 
procestijden  en  vertragingsfactoren  kunnen  plaatsvinden  zijn: 

a.  Er  moet  een  lijst  getoond  worden  van  alle  bestaande  processen  in 
AOW.  Indien  er  hiervan  een  wordt  geselecteerd  dan  kunnen  de  pro¬ 
cestijden  en  de  vertragingsfactoren  direct  gewijzigd  worden; 

b.  Saven  van  procestijden; 

c.  Laden  van  procestijden; 
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d.  Default  voor  procestijden; 

e.  Het  aanpassen  van  procestijden  en  vertragingsfactoren. 

NB:  Procestijden  kunnen  onafhankelijk  van  de  infrastructuur,  organisatie 
en  resources  gebruikt  worden.  Echter,  veelai  zullen  de  procestijden 
aangepast  worden  in  het  kader  van  een  bepaalde  vliegbasis  in  samen- 
hang  met  een  bepaald  scenario.  Daardoor  zijn  procestijden  min  of 
meer  gebonden  aan  een  bepaalde  infrastructuur  en  scenario  (dit  zal  in 
de  praktijk  blijken)  maar  kan  in  theorie  los  gezien  worden  van  de  in¬ 
frastructuur  en  organisatie. 

7.2.2  Globale  opzet  van  dit  user-interface  deel 

De  gebniikersinterface  zal  zoveel  mogelijk  lijken  op  die  van  het  AOW-III  systeem 
om  (1)  de  inwerktijd  van  de  gebruiker  te  verkorten  omdat  deze  het  AOW-III  sys¬ 
teem  al  kent  en  (2)  vanwege  de  al  ter  beschikking  staande  software  (hergebruik). 
Qua  werking  van  de  user-interface  (vanuit  de  gebruikerskant  gezien)  komt  het  er 
grofweg  op  neer  dat  de  gebruiker  de  objecten  kiest  uit  voorgedefmieerde  lijsten  en 
deze  vervolgens  met  de  muis  op  de  map  plaatst.  Tijdens  het  plaatsen  van  een 
object  zal  rechts  op  het  scherm  (de  plaats  waar  nu  de  ordermodule  in  AOW-III  is 
geplaatst)  een  editveld  verschijnen  waarin  eventueel  direct  een  aantal  wijzigingen 
op  kunnen  worden  uitgevoerd.  Het  systeem  zal  echter  zelf  altijd  een  default  waar- 
de  geven  bij  de  parameters  van  de  objecten.  Het  zal  ook  mogelijk  zijn  om  een 
tekstuele  lijst  op  te  roepen  (pulldown  of  tote-achtig)  waarin  alle  op  de  map  ge- 
plaatste  objecten  zijn  opgenomen.  Door  hier  een  uit  te  kiezen  zal  het  bijbehorende 
editveld  verschijnen  en  een  mark-spot  verschijnen  bij  het  object  op  de  map  (in  de 
vorm  van  een  rode  cirkel). 

De  procesparameters  en  vertragingsfactoren  kunnen  aangepast  worden  middels  een 
editveld  na  het  selecteren  van  een  proces  in  de  procesparameter-tote.  Vervolgens 
kan  de  procesparameter-file  bewaard  worden.  Met  behulp  van  het  filemanagement- 
systeem  moet  het  dus  mogelijk  zijn  diverse  links  te  leggen  tussen  de  diverse  gecre- 
eerde  files.  Aan  de  hand  van  een  logisch  gekozen  naam  kan  dan  binnen  het  AOW- 
III  systeem  in  een  keer  een  bepaalde  situatie  geladen  worden. 

Alle  elementen  uit  de  genoemde  punten  LA  (paragraaf  7.2.1)  zullen  geintegreerd 
worden  tot  een  consistent  en  logisch  geheel  waarbij  zoveel  mogelijk  functies 
gegroepeerd  zullen  worden  (zoals  bijvoorbeeld  de  load/save/clear-opties  bij  vrij- 
wel  alle  punten).  Zie  hiervoor  hoofdstuk  zes. 


7.3  Scenario  editor 

7.3.1  Inleiding 

Dit  hoofdstuk  gaat  stapsgewijs  alle  functies  van  de  scenario-editor  na  en  presen- 
teert  deze  afzonderlijk  met  inbegrip  van  invoer  en  uitvoer.  Er  wordt  gekeken  naar 
het  user-interface  ontwerp,  overeenkomsten  en  verschillen  tussen  de  functies  en  de 
eventuele  impact  op  het  AOW-III  systeem  (filemanagement). 
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7.3.2  F  unctionaliteiten 

De  scenario  editor  kan  worden  onderverdeeld  in  twee  type  invoer: 

1 .  Het  draaiboek  van  de  oefening; 

2.  De  commando  structuur  (autorisatie  scherm  (map/tote),  orders,  mail,  objec- 
ten  en  spelers-structuur). 

ad  1 :  Draaiboek  oefening 

Aan  de  hand  van  deze  editor  kan  het  gehele  draaiboek  voor  een  sessie  ont- 
worpen  worden.  Dit  betreft  de  definitie  van  invloeden  van  buitenaf  op  de 
vliegbasis.  Hierbij  kan  worden  gedacht  aan: 

-  Tasking  door  CAOC,  wings  ops  of  Klu  staf: 

.  airtasks,  met  missiegrootte,  configuratie  (wapen,  brandstof,  wel/geen 
ECM),  Time  Over  Target,  uitvoerend  squadron; 

.  X-servicing  missies; 

.  QRA  taak. 

-  Vijandelijke  luchtaanval,  met  verstoringen: 

tijdstip  met  locaties  van  UXO’s,  craters,  fires,  contamination,  power 
failures,  communication  failures. 

-  Vijandelijke  grondaanval,  met  verstoringen: 

.  tijdstip  met  locaties  van  intruders. 

-  Beschikbare  versterkingen: 

.  extra  personeel  en  materieel  (soorten  en  aantal), 

-  Wijzigingen  op  de  beginsituatie: 

.  deel  van  materieel  beschadigd  na  aantal  dagen  oorlogvoeren; 
deel  van  materieel  nog  niet  gearriveerd  op  out  of  area  basis). 

De  bestaande  methodiek  op  basis  van  orders  in  het  huidige  AOW  systeem  is 
bruikbaar  m.u.v.  de  definitie  van  de  verstoringen  van  een  air  attack.  Het 
moet  mogelijk  zijn  de  locaties  van  de  verstoringen  rechtstreeks  op  de  kaart 
(map)  aan  te  geven  met  behulp  van  de  muis  in  plaats  van  via  aparte  create- 
orders  deze  verstoringen  aan  te  maken  op  een  bepaalde  locatie  met  xy-coor- 
dinaten. 

Bij  deze  optie  verschijnt  op  de  plek  van  de  totes  en  maps  automatisch  een 
overzicht  van  de  orders  uit  het  scenario.  Aan  de  rechterkant  kunnen  orders 
gekozen  en  ingevoerd  worden,  zoals  bekend  is  uit  het  AOW-III  systeem. 
Overige  acties  met  betrekking  tot  de  draaiboek  oefening  zijn: 

a.  Invoeren  orders.  Dit  zal  gelijk  zijn  aan  de  huidige  ordermodule  in  het 
staf-station  met  een  uitbreiding  van  de  order  air  attach, 

b.  Deleten  van  orders; 

c.  Wijzigen  van  orders; 

d.  Saven  van  een  scenario; 

e.  Laden  van  een  scenario; 

f  Clearen  van  een  scenario; 
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ad  2:  Commando  struct uiir 

De  commando  stnictuur  wordt  gebruikt  om  de  managementsstructuur  op  een 
vliegbasis  te  definieren.  Aan  de  hand  van  deze  tool  kan  bijvoorbeeld  de 
WOLF-organisatiestructuur  worden  ingevoerd  of  kunnen  andere  organisa- 
tiestructuren  worden  ingevoerd  of  worden  getest.  Om  dit  te  realiseren  moet 
het  met  deze  editor  mogelijk  zijn  de  autorisaties  van  gegevens  (totes/maps), 
orders,  mail,  objecten  en  de  spelersstructuur  te  kunnen  beinvloeden,  te  we- 
ten: 

i.  Spelersstructuur. 

ii.  Scherm  (map/tote); 

iii.  Orders; 

iv.  Mail  (wat  gaat  naar  wie); 

V.  Objecten  (object-autorisatie); 

De  acties  die  bij  de  creatie  van  de  commando  structuur  kunnen  plaatsvinden 
zijn: 

a.  Kiezen  van  het  soort  invoer  (scherm  (map/tote),  orders,  mail,  objecten 

of  spelers-structuur); 
b  1 .  Spelersstructuur 

Hier  kan  men  een  lijst  samenstellen  van  de  gebruikers  van  het  sys- 
teem:  de  spelers-structuur. 
b2.  Scherm  (map/tote): 

Er  zal  een  lijst  van  gebruikers  verschijnen  waar  men  met  behulp  van 
checkboxes  een  bepaalde  tote  of  map  aan  of  uit  kan  zetten,  afhanke- 
lijk  of  de  gebruiker  geauthoriseerd  is  de  tote  of  map  te  zien; 
b3.  Orders: 

Er  zal  een  lijst  van  gebruikers  verschijnen  waaruit  men  kan  kiezen. 

Per  gebruiker  wordt  dan  een  lijst  van  orders  gepresenteerd.  De  orders 
kunnen  dan  worden  aan-  of  uitgezet.  Een  tweede  optie  is  het  presente- 
ren  van  de  orders  waarover  de  gebruiker  reeds  beschikt  en  een  lijst 
van  alle  mogelijke  orders  (vergelijk  dit  met  de  lijst  ALL  AVAILABLE 
ORDERS  op  het  staf-station).  Nu  kan  men  orders  uit  de  totaallijst 
‘kopieren’  naar  de  gebruikerslijst  of  juist  orders  ‘deleten’  uit  de  ge- 
bruikerslijst; 
b4.  Mail: 

Evenals  bij  het  scherm  en  de  orders  kan  men  kiezen  uit  een  gebruiker 
en  vervolgens  bepalen  welke  mail-boodschap  naar  de  gebruiker  ver- 
stuurd  kan  worden; 
b5.  Objecten: 

Ook  nu  kan  men  een  gebruiker  selecteren  waarvan  alle  objectautori- 
saties  getoond  worden.  Dit  is  in  feite  een  lange  lijst  van  alle  objecten 
op  de  vliegbasis  (object  =  type  [AC/AD/BD/DB/...]  +  objectnummer) 
die  vervolgens  aan-  of  uitgezet  kan  worden.  De  objecten  moeten  ge- 
selecteerd  kunnen  worden  op  shiftnummer,  groepsnummer,  categorie 
en  individueel; 
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En  voor  alle  punten  bl  t/m  b5  geldt  ook: 

c.  Saven  van  de  autorisatie; 

d.  Laden  van  de  autorisatie; 

e.  Clearen  van  de  autorisatie; 

7.3.3  Globale  opzet  van  dit  user-interface  deel 

Zoals  in  paragraaf  7.2,2  al  werd  vermeld  zal  de  user-interface  zoveel  mogelijk 
lijken  op  die  van  het  AOW-III  systeem,  De  scenario-editor  zal  worden  geintegreerd 
in  dezelfde  tool  als  de  static  editor.  In  principe  is  dan  de  opbouw  ook  al  bekend: 
net  als  bij  de  static  kan  de  gebruiker  bij  de  scenario  editor  met  een  tweetal  knop- 
pen  aangeven  wat  ingevoerd  gaat  worden:  het  draaiboek  of  de  autorisaties.  Het  zal 
er  op  neerkomen  dat  de  beschreven  static  editor  wordt  uitgebreid  met  een  tweetal 
extra  knoppen  waarmee  deze  twee  zaken  kunnen  worden  geselecteerd.  Hiermee 
wordt  tevens  verkregen  dat  beide  tools  consistent  en  overzichtelijk  worden  geinte¬ 
greerd. 


7.4  Filemanagement-systeem 

7.4.1  Inleiding 

Vanwege  de  grote  diversiteit  in  de  files  die  de  static-  en  de  scenario-tool  produce- 
ren  is  het  noodzakelijk  hiervoor  een  filemanager  te  ontwerpen  die  eenvoudig  en 
snel  een  link  legt  tussen  de  geproduceerde  files.  Doel  hiervan  is  om  het  AOW-III 
systeem  overzichtelijk  en  eenvoudig  bedienbaar  te  houden  en  fouten  uit  te  sluiten. 
Het  filemanagement-systeem  moet  de  mogelijkheid  bieden  om  door  middel  van 
een  keyword  (reference  name)  een  gehele  vliegbasis-definitie  te  laden.  Zodoende 
is  het  mogelijk  om  door  middel  van  een  actie  van  de  gebruiker  zowel  een  infra- 
structuur,  organisatie,  resources  als  een  commando-structuur  te  laden  die  door 
middel  van  de  tools  zijn  gecreeerd. 

Dit  hoofdstuk  gaat  in  op  het  beheer  van  de  diverse  files  en  toont  aan  in  welke 
volgorde  files  aangemaakt  dienen  te  worden  en  welke  files  gerelateerd  zijn  aan 
welke  andere  files. 

7.4.2  Inventarisatie  van  alle  type  files 

Zowel  de  static-  als  de  scenario  editor  produceren  files.  De  meeste  van  deze  files 
houden  verband  met  elkaar  terwijl  er  ook  files  geproduceerd  worden  die  autonoom 
zijn.  Tabel  7.4  toont  een  overzicht  van  de  geproduceerde  files  en  is  tevens  een 
overzicht  van  de  tools  uit  de  hoofdstukken  drie  en  vier  met  daarbij  een  beschrij- 
ving  van  de  files  die  ze  produceren  (vergelijk  ook  tabel  6,1  paragraaf  6.3). 
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Tabel  7.4:  Overzicht  van  alle  files  geproduceerd  door  de  tools. 


Deel 

Categorie 

Functionaliteit 

File(s) 

Toelichting 

Static 

Airbase 

Infrastructuur 

Organisatie 

Resources 

#static.dat 

#dynamic.dat 

#dynamic.dat 

Bevat  alle  BD  van  een  airbase; 

Bevat  alle  PS  van  een  airbase; 

Bevat  alle  AC/AD/SU/TR  van  een  airbase; 

Processen 

Processen 

nieuw 

Bevat  procestijden  en  vertragings-faktoren; 

Scenario 

Spelers 

Spelerssetup 

Autorisaties 

#playnam.dat 

#player.dat 

#meslist.dat 

#autinfo.dat 

Bevat  spelersstructuur; 

Bevat  order-autorisaties; 

Bevat  mail-autorisaties; 

Bevat  map/tote  autorisaties; 

Objecten 

Autorisatie 

nieuw 

Bevat  object-autorisaties; 

Orders 

Draaiboek  sessie 

orderfiles  (1) 
orderfiles  (2) 

Bevat  scenario’s  voor  een  sessie; 

Bevat  bewaarde  sessies  (orders); 

Exercise 

Exercise 

Exercise  manager 

#sesmerg.dat 

Bevat  een  compilatie  van  diverse  (hierboven 
vermelde)  files  die  te  zamen  een  exercise 
vormen. 

7 A3  Relaties  tussen  de  files 

Zoals  al  in  paragraaf  6.3.4  was  vermeld  is  het  noodzakelijk  de  vliegbasis  in  een 
bepaalde  volgorde  te  ontwerpen.  Zo  is  het  onmogelijk  om  eerst  een  organisatie  of 
om  resources  te  ontwerpen  en  dan  pas  de  infrastructuur:  de  infrastructuur  is  name- 
lijk  de  basis  waarop  de  organisatie  en  de  resources  ontworpen  worden.  Figuur  7.1 
toont  de  volgorde  waarop  de  gebruiker  de  verschillende  onderdelen  van  de  vlieg¬ 
basis  (inclusief  scenario)  kan  definieren.  Volgens  figuur  7.1  heeft  de  gebruiker 
drie  mogelijke  startpunten,  te  weten  Start  A,  Start  B  en  Start  C  (beschrijving 

Z.O.Z.). 
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Figuur  7.1:  Relaties  tussen  de  tools. 

Start  A 

Ten  eerste  kan  de  gebruiker  beginnen  met  het  ontwerpen  van  de  vliegbasis  aan  de 
hand  van  de  static-editor.  Binnen  de  static-editor  moet  eerst  de  infrastructuur  (#1) 
van  de  vliegbasis  vastgelegd  worden.  De  infrastructuur,  welke  de  definitie  van 
gebouwen,  runways  en  taxiways  bevat,  is  de  basis  van  de  vliegbasis.  Pas  daama 
kunnen  de  organisatie  (personeel,  #2)  en  de  resources  (materieel,  #3)  gedefinieerd 
worden.  Per  infrastructuur  kunnen  meerdere  organisaties  en  resources  ontworpen 
worden.  Als  de  gehele  vliegbasis  gedefinieerd  is  dan  kan  het  draaiboek  (#6)  ont¬ 
worpen  worden. 

NB;  Uit  het  voorgaande  volgt  dat  op  basis  van  een  infrastructuur  meerdere  orga¬ 
nisaties  of  resources  gedefinieerd  kunnen  worden  en  dat  het  dus  niet  moge- 
lijk  is  om  een  organisatie  van  infrastructuur  A  te  laden  bij  infrastructuur  B. 
De  exercise-manager  moet  dit  soort  situaties  voorkomen. 

NB:  Ook  het  draaiboek  is  afhankelijk  van  de  gebruikte  infrastructuur.  Een  van  de 
redenen  is  bijvoorbeeld  het  creeren  van  een  air  attack.  Hierbij  kunnen  dis- 
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turbances  aangegeven  worden  die  meestal  worden  geplaatst  op  een  runway. 
De  runways  worden  gedefinieerd  in  de  infrastructuur  waaruit  volgt  dat  het 
draaiboek  afhankelijk  is  van  de  gebruikte  infrastructuur.  Overigens  is  het 
draaiboek  niet  afhankelijk  van  de  gebruikte  spelersstructuur. 

Start  B 

Ten  tweede  kan  de  gebruiker  de  spelersstructuur  (#4)  definieren:  dit  zijn  de  spelers 
van  het  systeem.  Wanneer  dit  gedefinieerd  is  kan  de  gebruiker  de  diverse  totes  en 
maps  definieren  waartoe  de  spelers  geautoriseerd  zien,  alsmede  de  autorisaties  van 
orders  en  mail  (#8) .  Ook  hier  geldt  dat  per  spelersstructuur  meerdere  autorisaties 
gedefinieerd  kunnen  worden.  Indien  nu  zowel  de  vliegbasis  als  de  spelersstructuur 
gedefinieerd  zijn  dan  kan  de  gebruiker  de  autorisaties  van  alle  op  de  vliegbasis 
aanwezige  objecten  definieren  (#7). 

Start  C 

Ten  derde  kan  de  gebruiker  altijd  de  procestijden  en  vertragingsfactoren  definieren 

(#5). 

Om  de  gebruiker  te  assisteren  bij  het  definieren  van  de  exercise  wordt  een  exerci¬ 
se-manager  ontworpen.  Deze  manager  stuurt  de  gebruiker  zodanig  dat  de  gebruiker 
alleen  die  categorieen  kan  definieren  welke  toegestaan  zijn.  Tenslotte  kan  de 
gebruiker  de  exercise  onder  een  naam  opslaan  zodat  in  het  AOW-III  systeem  de 
gehele  definitie  onder  een  naam  ingelezen  kan  worden.  Daartoe  zal  de  exercise- 
manager  intern  een  link  leggen  tussen  de  infrastructuur  en  de  gedefinieerde  organi- 
satie  en  resources. 


Samenvattend: 

•  Van  de  vliegbasis  zal  eerst  de  infrastructuur  gedefinieerd  moeten  worden  en 
daama  pas  de  organisatiestructuur  en  de  resources. 

•  Het  draaiboek  kan  pas  worden  gedefinieerd  nadat  de  definitie  vliegbasis  is 
vastgelegd. 

•  De  spelersstructuur  is  onafhankelijk  van  de  gebruikte  vliegbasis. 

•  De  autorisaties  kunnen  pas  worden  gedefinieerd  nadat  de  vliegbasis  en  de 

spelersstructuur  is  vastgelegd. _ 


7.4,4  Globale  opzet  van  dit  user-interface  deel 

De  gebruiker  heeft  de  mogelijkheid  om  een  complete  vliegbasis,  inclusief  scenario, 
op  te  slaan  onder  een  naam,  de  exercise-naam.  Aan  de  hand  van  deze  naam  kan  de 
gebruiker  op  het  staf-station  een  gehele  vliegbasis  met  scenario  laden. 
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7,5  Test 

7.5. 1  Functionaliteiten 

Binnen  de  tools  dient  een  optie  te  worden  ingebouwd  om  de  gehele  exercise  te 
controleren  op  fouten  en  gebreken.  Het  enige  dat  niet  gecontroleerd  kan  worden  is 
het  draaiboek  omdat  hiervoor  het  simulatiesysteem  zelf  nodig  is.  De  oplossing 
hiervoor  is  het  draaiboek  te  af  te  spelen  op  het  simulatie-station  als  controle  en  de 
simulatie  via  het  stafstation  te  volgen. 

Tabel  7.5  geeft  een  overzicht  van  aspecten  waarop  de  exercise  gecontroleerd  dient 
te  worden. 

Tabel  7.5:  Overzicht  van  test-items. 


Test  Items 

Ontbrekende  objecten 
Objecten  op  een  verkeerde  locatie 

Spelers  zonder  bevoegdheden  (maps,  totes,  mail,  orders,  objecten) 

Informatie  (maps,  totes,  mail),  orders  of  objecten  waartoe  niemand  bevoegd  is 


Niet  elke  foutmelding  hoeft  per  definitie  een  font  te  zijn.  Er  kan  bewust  voor 
gekozen  worden  om  bijvoorbeeld  een  bepaalde  order  aan  niemand  toe  te  kennen  of 
om  een  bepaalde  speler  helemaal  geen  bevoegdheid  te  verstrekken  tot  het  geven 
van  orders  (hij  mag  bv.  alleen  informatie  zien)..  In  die  gevallen  moet  het  in  ieder 
geval  mogelijk  zijn  de  exercise  te  bewaren  en  daar  later  een  spelsessie  mee  te  gaan 
spelen. 


7.5.2  Globale  opzet  van  dit  user-interface  deel 

De  test  zal  worden  geintegreerd  in  dezelfde  tool  als  de  static-editor,  scenario-editor 
en  file-manager.  Als  de  test  is  uitgevoerd  krijgt  de  gebruiker  een  overzicht  in  de 
vorm  van  een  lijst  waarin  alle  geconstateerde  fouten  of  onvolkomenheden  zijn 
opgenomen.  Nadat  de  gebruiker  zijn  fouten  heeft  hersteld  zal  hij  opnieuw  de  test 
moeten  laten  uitvoeren  om  te  zien  of  hij  daadwerkelijk  alle  fouten  heeft  verbeterd. 


8. 


Presentatie  van  de  AOW-III  Tools 


8.1  Inleiding 

In  dit  hoofdstuk  zal  de  gehele  opbouw  en  de  specifiekere  werking  van  de  user- 
interface  uiteen  worden  gezet  op  basis  van  de  voorgaande  hoofdstukken  (6  en  7). 
Dit  omvat  de  static-  en  de  scenario-editor  en  de  filemanager. 


8.2  Globale  schermopbouw 

Het  scherm  wordt  gemakshalve  opgedeeld  in  vier  delen  waama  in  deze  paragraaf 
de  functionaliteit  van  ieder  deel  toegelicht  zal  worden;  zie  figuur  8.1: 


3 


2 


4 


Indeling  van  de  gebieden: 


la,  b  Multi-functionele  window(s) 

2  Orderwindow;  objectedit 

3  Menu 

4  Extra  informatie 


Figuur  8.1:  Schematische  indeling  van  het  AOW-III  scherm. 


Wat  direct  opvalt  is  de  overeenkomst  met  het  AOW-III  systeem:  de  indeling  is  dan 
ook  dezelfde  als  in  figuur  4. 1  (paragraaf  4.2).  De  indeling  van  de  schermen  is 
hetzelfde  gebleven  behalve  dat  een  aantal  windows  zijn  uitgebreid  of  zijn  aange- 
past.  Een  korte  opsomming  van  de  functionaliteiten  van  de  vier  schermdelen: 


Scherm  1:  informatieschermen  (map,  tote,  orders,  procestijden,  etc) 

Net  als  in  het  AOW-III  systeem  wordt  in  dit  deel  de  gegevens  uit  het  systeem 
gepresenteerd  in  de  vorm  van  maps,  totes,  orderoverzicht,  clipboard,  etc.  Ook  is 
het  scherm  te  splitsen  in  twee  deelschermen  en  zijn  alle  acties  uit  het  AOW-III 
systeem  hier  ook  geldig  (zoals  zoomen,  informatie  opvragen,  marken  (clipboard), 
grids,  etc).  Indien  een  map  geselecteerd  is  dan  kan  met  behulp  van  de  muis  een 
object  op  de  map  geplaatst  worden.  Uiteraard  wordt  de  informatie  in  de  totes  dan 
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ook  overeenkomstig  aangepast.  Het  aantal  type  informatieschermen  is  echter  wel 
uitgebreid.  Zo  komt  er  onder  andere  een  tekstueel  overzicht  van  processen 
(procestijden-edit)  en  alle  mailberichten  (wat  gaat  naar  wie).  Aan  de  hand  van  een 
editscherm  die  wordt  opgenomen  in  schemideel  3  kunnen  die  gegevens  aangepast 
worden. 

Deel  2:  orderinvoer,  object  edit 

Indien  een  scenario  ingevoerd  wordt  dan  is  in  dit  deel  van  het  scherm  het  reguliere 
order-edit  scherm  zichtbaar  zoals  dat  nu  wordt  gebruikt  in  het  AOW-III  systeem. 
Indien  een  infrastructuur,  organisatie  of  resource  gecreeerd  wordt  dan  is  hier  een 
object-editscherm  zichtbaar  waarin  alle  gegevens  van  het  gecreeerde  object  getoond 
worden  en  aangepast  kunnen  worden. 

Scherm  3:  drie  toolbars 

Aan  de  hand  van  de  gepresenteerde  buttons  in  deze  toolbars  kunnen  alle  type  acties 
ingesteld  worden.  Afhankelijk  van  de  gekozen  type  actie  (invoeren  infrastruc- 
tuur/organisatie/resources/etc.)  wordt  een  deel  van  de  toolbars  aangepast  en  worden 
een  aantal  relevante  buttons  gepresenteerd  die  van  belang  zijn  voor  deze  actie.  Een 
klein  aantal  buttons  uit  het  AOW-III  systeem  zijn  terug  te  vinden  in  deze  toolbars. 

Deel  4:  online  help-informatie 

Dit  is  de  online  help-informatie  zoals  deze  thans  in  het  AOW-III  systeem  wordt 
gebruikt. 

Deel  1  &  2  samen 

In  het  geval  dat  de  filemanager  wordt  opgestart  dan  gebruikt  deze  het  scherm  ter 
grootte  van  de  schermdelen  twee  en  drie.  Exacte  invulling  hierover  in  paragraaf  8.6. 


8.3  Toolbars 

Figuur  8.2  toont  een  globale  (schematische)  schermopbouw  van  de  AOW-tools  met 
betrekking  tot  de  toolbars  (dit  zijn  de  drie  ‘regels’  met  knoppen).  NB:  de  in  de 
schermvoorbeelden  gebruikte  namen  en  afkortingen  zijn  niet  representatief  voor  de 
namen  in  het  definitieve  systeem. 


j  AIRBASE  1 

/  PLAYERS  V  AUTHORIZE  \j  SCENARIO  \j  EXERCISE  \j  TEST  \ 

\  OBJECTS 

CLUSTERS  1 

PROCESSES  1 

LOAD 

SAUE  j  CLEAR  ; 

Figuur  8.2:  Schematische  opbouw  van  de  toolbars. 


Globale  toelichting 

In  principe  is  de  user-interface  identiek  aan  het  AOW-III  systeem,  behalve  de 
tweede  en  derde  toolbar-regels  van  het  scherm.  De  eerste  toolbar-regel  is  identiek 
aan  die  van  het  AOW-III  systeem:  een  knop  voor  het  beeindigen  van  de  applicatie 
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en  rechts  daarvan  een  blauwe  balk  met  programma-informatie.  De  tweede  toolbar- 
regel  is  ingrijpend  gewijzigd.  Links  op  deze  bar  treft  men  een  zestal  knoppen  aan 
(tabs)  waarvan  ieder  een  bepaald  type  invoer  betekent  (overeenkomstig  met  tabel 
6.1,  paragraaf  6.3  plus  de  exercise-manager).  In  figuur  8.2  is  deze  ingesteld  op 
airbase  hetgeen  erop  duidt  dat  de  gebruiker  de  airbase  aan  het  definieren  is.  De 
derde  toolbar-regel  wordt  bepaald  aan  de  hand  van  de  gekozen  type  invoer:  dit  zijn 
dus  de  specifieke  buttons  behorende  bij  dit  ene  type  invoer.  Voor  de  airbase  bete¬ 
kent  dit  dat  gekozen  kan  worden  uit  de  objects,  clusters  en  processen.  Voorts  bevat 
de  tweede  toolbar-regel  aan  de  rechterkant  een  drietal  buttons:  load,  save  en  clear. 
Met  deze  buttons  kan  men  per  gekozen  tab  kan  een  definitie  laden,  bewaren  of 
verwijderen  (een  definitie  is  een  airbase,  een  player-def,  etc).  Met  behulp  van  de 
print-button  kan  elke  willekeurig  geselecteerde  lijst  of  grafische  map  geprint  wor¬ 
den  (dus  totes,  mail,  orders,  maps,  etc). 

De  rest  van  deze  paragraaf  is  een  toelichting  op  de  tab-keuzemogelijkheden. 


Airbase  -  Objects 


s 

■ 

r 

AIRBASE  ^ 

1  PLAYERS 

X. 

AUTHORIZE  y  SCENARIO  ]J  EXERCISE  \j 

TEST  \ 

€ 

~  OBJECT^  1 

CLUSTERS 

I 

PROCESSES  i 

LOAD 

SAUE  ; 

CLEAR  1 

Figuur  8J:  Layout  van  de  infrastructuur-editor. 

Met  de  objects-editor  kan  een  vliegbasis  ontworpen  worden.  Dit  betekent  dat  de 
gebruiker  op  een  map  de  infrastructuur,  de  organisatiestructuur  en  de  resources  kan 
definieren  en  deze  daama  kan  saven  onder  een  bepaalde  naam.  Voor  het  verwijde¬ 
ren  (deleten)  van  gedefmieerde  objecten  (ook  bij  de  organisatie  en  de  resources) 
wordt  in  de  tote-  en  mapwindow  een  delete-hutton  opgenomen  (nu  niet  zichtbaar). 
Indien  een  object  geselecteerd  is  dan  kan  aan  de  hand  van  de  delete-button  het 
object  verwijderd  worden. 

Airbase  -  Clusteraccess 


j  AIRBASE  y  PLAYERS  \j  AUTHORIZE  \J  SCENARIO  \J  EXERCISE  \/  TEST  \ 

1  OBJECTS  1  CLUSTERS 

PROCESSES  i 

LOAD 

SAUE  i 

CLEAR  i 

Figuur  8.4:  Layout  van  de  clusteraccess-editor. 


Vanaf  het  moment  dat  een  infrastructuur  is  gedefinieerd  kan  de  gebruiker  de  clus¬ 
ters  op  de  vhegbasis  aangeven.  Clusteraccess  wordt  bepaald  door  de  taxiways  die 
de  ene  cluster  met  de  andere  cluster  verbinden.  De  gebruiker  kan  dit  aangeven  door 
cluster  te  selecteren  uit  een  lijst  en  vervolgens  een  selectbox  over  de  map  te  plaat- 
sen.  Alle  objecten  binnen  de  selectbox  behoren  tot  de  uit  de  lijst  geselecteerde 
cluster.  Alle  taxiways  die  over  de  grens  van  dit  cluster  gaan  zorgen  voor  de  cluster- 


access. 
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Airbase  -  Procestijden  en  vertragingsfaktoren 


1  AIRBASE  ^ 

PLAYERS  \J  AUTHORIZE  \ 

/  SCENARIO  V  EXERCISE  \J  TEST  \ 

#: 

1  OBJECTS 

CLUSTERS  1  PROCESSES 

LOAD 

SAUE  i 

CLEAR  : 

Figuur  8.5:  Layout  van  de  procestijden  en  vertragingsfaktoren-editor. 


Bij  de  procestijden-  en  vertragingsfactoren-editor  kan  niet  gekozen  worden  nit 
klassen.  Het  enige  wat  hier  gedaan  kan  worden  zijn  de  procestijden-  en  vertragings- 
factoren  aanpassen  die  in  een  tote-achtige  lijst  worden  gepresenteerd.  Door  een 
regel  uit  de  lijst  aan  te  wijzen  zal  in  het  editscherm  (voorheen  ordermodule)  rechts- 
onder  op  het  scherm  (zie  figuur  8.1  deel  3)  de  parameters  staan  die  aldaar  aangepast 
kunnen  worden. 

Qua  informatieschermen  kan  dus  niet  uit  een  aantal  schermen  gekozen  worden: 
alleen  een  lijst  (in  de  vorm  van  een  tote)  van  procestijden  en  vertragingsfactoren 
kan  bekeken  worden.  Voorts  zie  paragraaf  8.4  en  tabel  8.1. 


Spelersstructuur 


El 

r 

AIRBASE  y  PLAYERS  \ 

[  AUTHORIZE  y  SCENARIO  y  EXERCISE  \[ 

TEST  \ 

1  LOAD  1  SAUE  : 

CLEAR  ; 

Figuur  8.6:  Layout  van  de  spelersstructuur-editor. 


Deze  optie  toont  een  scherm  met  een  aantal  voorgedefmieerde  spelemamen.  Indien 
een  speler  niet  gedefinieerd  is  dan  verschijnt  voor  deze  speler  een  lege  regel.  Door 
nu  een  speler  in  de  lijst  te  selecteren  met  de  muispijl  kan  de  naam  aangepast  wor¬ 
den. 


Autorisaties  -  Maps  &  Totes 


|^■|||[■ 

/  AIRBASE  Y  PLAYERS  \/flUTHORIZE| 

/  SCENARIO  y  EXERCISE  \J  TEST  \ 

1  MAPS/TOTES 

ORDERS 

MAIL  1 

OBJECTS 

1  LOAD 

SAUE  1 

CLEAR  ; 

Figuur  8. 7:  Layout  van  de  windows-autorisatie  editor. 


In  de  tote  (schermdeel  2)  verschijnt  een  overzicht  van  de  beschikbare  windows 
voor  speler  Player  1.  De  gebruiker  kan  nu  aangeven  welke  windows  tot  de  be- 
schikking  van  Player  1  staat.  Voor  het  definieren  van  een  andere  speler  dient  via  de 
pulldown-lijst  een  andere  speler  geselecteerd  te  worden. 
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Autorisaties  -  Orders 


j  AIRBASE  y  PLAYERS  ^ 

/authorize^ 

J  SCENARIO  \ 

/  EXERCISE  V  TEST  \ 

#: 

MAPS/TOTES  i 

1  ORDERS 

MAIL  j 

OBJECTS 

LOAD 

SAOE  1  CLEAR  : 

Figuur  8.8:  Layout  van  de  orders-autorisatie  editor. 

Evenals  bij  de  autorisatie  van  windows  verschijnt  in  schermdeel  2  een  tote  met 
daarin  een  overzicht  van  alle  beschikbare  orders  voor  Player  I.  De  gebruiker  kan 
nu  aangeven  welke  orders  voor  Player  I  beschikbaar  zijn.  Voor  het  definieren  van 
een  andere  speler  kan  via  de  pulldown-lijst  een  andere  speler  gekozen  worden. 

Autorisaties  -  Mail 


a 

L 

AIRBASE  y  PLAYERS  \ 

/authorize 

y  SCENARIO  \ 

1  EXERCISE 

'Y 

TEST  \ 

1  MAPS/TOTES  1 

ORDERS 

{  MML  ^ 

OBJECTS 

□ 

1  LOAD 

SAOE  ; 

CLEAR 

Figuur  8.9:  Layout  van  de  mail-autorisatie  editor. 

Evenals  bij  de  autorisatie  van  windows  verschijnt  in  schermdeel  2  een  tote  met 
daarin  een  overzicht  van  alle  beschikbare  mailberichten  voor  Player  1.  De  gebrui¬ 
ker  kan  nu  aangeven  welke  mailberichten  voor  Player  1  beschikbaar  zijn.  Voor  het 
definieren  van  een  andere  speler  kan  via  de  pulldown-lijst  een  andere  speler  geko¬ 
zen  worden. 


Autorisaties  -  Objecten 


/  AIRBASE  y  PLAYERS  yAUTHORIZEV  SCENARIO  \J  EXERCISE  1/  TEST  \ 

1  MAPS/TOTES  1 

ORDERS  1  MAIL  |  OBJECTS  | 

LOAD 

SAOE  i 

CLEAR  : 

Figuur  8.10:  Layout  van  de  windows-autorisatie  editor. 

Evenals  bij  de  autorisatie  van  windows  verschijnt  in  schermdeel  2  een  tote  met 
daarin  een  overzicht  van  alle  beschikbare  objecten  voor  Player  1.  De  gebruiker  kan 
nu  aangeven  welke  objecten  voor  Player  1  beschikbaar  zijn.  Voor  het  definieren 
van  een  andere  speler  kan  via  de  pulldown-lijst  een  andere  speler  gekozen  worden. 

Scenario 


■ 

■1 

/  AIRBASE  y  PLAYERS 

T 

AUTHORIZE  y  SCENARIO  \ 

/  EXERCISE  y 

TEST  \ 

LOAD 

SAUE  : 

CLEAR  S 

Figuur  8,11:  Layout  van  de  scenario-editor. 
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De  scenario-editor  lijkt  in  veel  opzichten  op  het  huidige  AOW-III  systeem  qua 
schemiopbouw.  De  gebruiker  kan  rechtsonder  in  het  scherni  orders  invoeren  en 
eventueel  gegeven  orders  aanpassen. 

Standaard  wordt  opgestart  met  het  order-overzicht  maar  de  gebruiker  heeft  in  dit 
geval  ook  de  beschikking  over  de  totes  en  de  maps. 


Exercise  manager 
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AIRBASE  \J  PLAYERS 
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SCENARIO  ^  EXERCISE  \j^ 

TEST  \ 

LOAD 

SAUE 

CLEAR  : 

Figuur  8J2:  Layout  van  de  exercise-editor. 

Aangezien  het  exercisemanagement-systeem  qua  schermopbouw  zeer  afwijkend  is 
ten  opzichte  van  de  besproken  tools  wordt  deze  apart  behandeld  in  paragraaf  8.6. 


Test 


/  MRBflSE  V  PLftYERS  ~\/  AUTHORIZE  \j  SCENARIO  \J  EXERCISE  \ 

TEST  \ 

m 

Figuur  8.13:  Layout  van  de  airbase-test. 


De  laatste  tabkeuze  laat  het  tool-systeem  de  airbase  op  alle  facetten  bekijken  en 
controleren.  Indien  bijvoorbeeld  een  bepaald  type  gebouw  niet  voorkomt  die  abso- 
luut  noodzakelijk  is  voor  het  spelen  van  een  sessie  dan  wordt  hiervan  melding 
gemaakt,  Ook  als  zou  blijken  dat  een  speler  geen  totes  en/of  maps  heeft,  wordt 
hiervan  melding  gemaakt. 


8.4  Informatieschermen 

In  principe  worden  de  informatieschermen  nauwelijks  aangepast,  hoogstens  uitge- 
breid.  De  huidige  schermen  in  het  AOW-III  systeem  betreffen  map,  tote,  orders, 
clipboard  en  AOW-mail.  Voor  de  tools  komt  de  AOW-mail  te  vervallen  maar 
worden  wel  de  windows  geintroduceerd  van  de  procestijden-  en  vertragingsfakto- 
ren-overzicht,  mail  (wat  gaat  naar  wie),  de  commandostructuur  (autorisaties  van 
maps,  tote’s,  orders  en  objecten)  en  de  spelersstructuur.  Het  principe  is  dat  afhan- 
kelijk  van  de  gekozen  tabfunctie  een  bepaalde  set  informatieschermen  ter  beschik¬ 
king  komt.  De  aan  de  ommezijde  opgenomen  tabel  8.1  geeft  een  overzicht  welke 
informatieschermen  beschikbaar  zijn  bij  welke  tabfuncties  en  wat  hierbij  de  even- 
tuele  wijzigingen  zijn  in  de  bestaande  informatieschermen: 
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label  8A:  Overzicht  van  de  functionaliteiten  van  de  informatieschermen. 


Tabfunctie 
[schermdeel  1] 

Beschikbare  informatiescher¬ 
men 

[schermdeel  2] 

Wijziging 

Infrastructuur,  organi- 

Maps 

Coordinaten-dispiay;  bij  de 

satie  en  resources 

muispijl  een  kruis  over  de 
gehele  map  (makkelijker  bij 
het  uitlijnen),  editscherm 
(schermdeel  3). 

Totes 

Editscherm  (schermdeel  3). 

Processen 

Procesoverzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Scenario 

Orders 

Editscherm  (schermdeel  3). 

Maps 

- 

Totes 

- 

Commandostructuur 

Spelers-overzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Totes/maps-overzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Orders-overzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Mail-overzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Object-overzicht  (nieuw) 

Editscherm  (schermdeel  3). 

Filemanagement 

File-overzicht  (nieuw) 

Volledig  nieuw  type  scherm. 

8.5  Editschermen 

Uitgaande  van  tabel  8.1  zijn  er  bij  acht  opties  editschermen  nodig  (afgezien  van  de 
ordermodule  die  niet  gewijzigd  wordt)  welke  in  deze  paragraaf  uiteengezet  wor- 
den. 

Infrastructuur,  organisatie  en  resources 

Wanneer  de  gebruiker  een  van  deze  drie  subopties  aan  het  definieren  is  dan  ver- 
schijnt  bij  elk  object  dat  gecreeerd  wordt  rechtsonder  in  het  scherm  een  editscherm 
met  daarin  alle  (default)gegevens  van  het  object.  Aan  de  hand  van  dit  editscherm 
kunnen  de  diverse  parameters  van  het  object  ingesteld  worden,  zoals  type  (open, 
hardened,  sheltered,  filtered),  beschikbare  ruimte,  etc.  Tevens  is  in  dit  editscherm 
continu  een  pulldownlijst  beschikbaar  met  daarin  alle  objecten  die  op  de  vliegbasis 
ziJn  gecreeerd.  Aan  de  hand  van  deze  lijst  kunnen  objecten  opgezocht  worden  en 
eventueel  gemodificeerd  worden. 

Processen:  procesoverzicht 

Bij  deze  optie  kunnen  de  procestijden  en  vertragingsfactoren  ingesteld  worden.  Er 
is  in  totaal  een  procestijd  per  proces  en  drie  vertragingsfactoren.  In  het  editscherm 
zullen  onder  elkaar  deze  vier  elementen  getoond  worden.  Met  behulp  van  de 
muispijl  kunnen  deze  gewijzigd  worden. 

Commandostructuur:  spelers-overzicht 

In  totaal  kent  AOW  12  spelers  waarvan  een  het  simulatiestation  is  en  een  het  staff 
station  is,  Er  zijn  dus  tien  spelers  definieerbaar.  In  de  tote  zal  het  overzicht  van  de 
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(on)gedefinieerde  spelers  komen.  Wanneer  een  speler  geselecteerd  wordt  dan 
verschijnen  de  gegevens  van  deze  speler  in  het  editscherm  rechtsonder  in  beeld. 
Het  enige  item  dat  kan  worden  ingesteld  is  de  spelersnaam  en  een  indicatie  of  de 
speler  gedefinieerd  is  (cq.  anderzijds  kan  men  niet  inloggen  als  deze  speler). 

Commandostructuur:  totes/maps-ovenicht 

In  een  tote-achtige  lijst  verschijnen  de  namen  van  alle  in  het  AOW-IH  systeem 
gebruikte  totes  en  maps.  Als  een  regel  hieruit  geselecteerd  wordt  dan  kan  in  het 
editscherm  aangegeven  worden  of  de  gebruiker  deze  window  wel  of  niet  kan  zien. 

Commandostructuur:  orders-overzicht 

In  een  tote-achtige  lijst  verschijnen  de  namen  van  alle  in  het  AOW-in  systeem 
bekende  orders.  Als  een  regel  hieruit  geselecteerd  wordt  dan  kan  in  het  editscherm 
aangegeven  worden  of  de  gebruiker  deze  order  wel  of  niet  kan  geven. 

Commando-overzicht:  mail-overzicht 

In  een  tote-achtige  lijst  verschijnen  de  berichten  van  alle  in  het  AOW-III  systeem 
bekende  mails.  De  mails  zullen  enigzins  cryptisch  overkomen  omdat  veelal  gege¬ 
vens  op  runtime-basis  aan  een  mail  worden  toegevoegd.  Als  een  regel  uit  het  mail- 
overzicht  geselecteerd  wordt  dan  kan  in  het  editscherm  aangegeven  worden  of  de 
gebruiker  dit  mailbericht  wel  of  niet  kan  ontvangen. 

Commando-overzicht:  object-overzicht 

In  een  tote-achtige  lijst  verschijnen  de  namen  van  alle  in  AOW-III  bekende  objec- 
ten  (per  regel  een  object  en  objectnummer).  Als  uit  deze  (lange)  lijst  een  regel  (= 
object)  wordt  geselecteerd  dan  kan  in  het  editscherm  aangegeven  worden  of  de 
gebruiker  tot  dit  object  wel  of  geen  autorisatie  heeft. 


8.6  Exercise-manager 

De  exercise-manager  draagt  er  voor  zorg  dat  alle  door  de  tools  gecreeerde  files  op 
een  eenvoudige  wijze  beheerd  kunnen  worden  zodat  het  laden  (of  bewaren)  van 
tegenstrijdige  informatie  uitgesloten  wordt.  Dit  kan  bereikt  worden  wanneer  het 
AOW-systeem  intern  registreert  welke  files  verband  houden  met  welke  andere 
files  en  dat  de  gebruiker  de  mogelijkheid  heeft  om  aan  combinaties  een  zogenaam- 
de  exercise  name  te  geven.  Aan  de  hand  van  een  exercise  name  kan  dan  in  het 
AOW-III  systeem  een  situatie  in  een  keer  geladen  worden  terwijl  het  intern  meer- 
dere  files  betreft.  Deze  paragraaf  introduceert  een  voorstel  hoe  de  schermpresenta- 
tie  van  de  exercise-manager  emit  kan  zien.  De  exercise-manager  wordt  over  het 
gehele  beeldscherm  geprojekteerd  vanwege  de  benodigde  mimte.  Daar  deze  pre- 
sentatie  anders  is  dan  van  de  static-  en  scenario-tool  wordt  in  figuur  8.14  het 
gehele  scherm  van  de  AOW-tools  gegeven  waarin  de  exercise-manager  actief  is. 
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3  TNO-FEL  (c>  1995 
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FiguurS.M:  Exercise-manager, 


8.7  Meldingen  en  overige  opties 

In  deze  paragraaf  worden  een  aantal  functionaliteiten  genoemd  die  niet  in  de  andere 
paragrafen  werden  genoemd  vanwege  het  algemene  karakter  of  vanwege  het  feit  dat 
ze  niet  in  de  vorige  paragrafen  ingedeeld  konden  worden. 

Acties 

•  Printoptie  Per  speler  moet  een  uitdraai  mogelijk  zijn  van  de  gedefmieerde 
objecten,  mail,  orders  en  windows. 


Foutmeldingen 
•  T.a.v.  de  static-editor 

-  Een  gebouw  is  vol:  er  past  geen  resource  of  personeel  meer  in; 

-  Runway/taxi  way:  alleen  horizontale  en/of  vertikale  runways  of  taxiways 
kunnen  ingevoerd  worden; 

-  Een  lokatie  is  al  bezet  (melding  indien  twee  objecten  van  het  BD-type  op  de 
dezelfde  locatie  wordt  gezet); 

-  Een  object  bestaat  al.  Deze  foutmelding  zal  voorkomen  indien  de  gebruiker 
een  object  handmatig  invoert  of  aanpast; 


TNO-rapport 


FEL-96-A284 


58 


•  T.a.v.  de  file-manager: 

-  File  bestaat  al  -  kan  niet  gesaved  worden; 

-  Disk  is  vol  -  er  kan  niets  meer  weggeschreven  worden; 

-  Wellicht  dient  er  vooraf  een  projectnaam  (exercise-name)  gedefinieerd  te 
worden. 
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9.  Systeemopzet  AOW-III  &  AOW-III  Tools 


In  dit  hoofdstuk  wordt  het  AOW-III  systeem  geschetst  zoals  dit  emit  komt  te  zien 
wanneer  het  geheel  afgerond  zou  zijn,  inclusief  de  tools  die  beschreven  zijn  in  de 
hoofdstukken  zes,  zeven  en  acht.  Tenslotte  wordt  een  overzicht  gegeven  van  de 
planning  en  de  bouw  van  het  AOW-III  systeem. 


9.1  Componenten 

Het  complete  AOW-III  systeem  dat  voor  ogen  staat  bevat  een  viertal  componenten, 
te  weten: 

1.  Presentatie  gegevens 

De  gegevens  uit  het  AOW-systeem  die  gepresenteerd  worden  bestaan  uit  een  tote 
en/of  een  map.  Hierin  zijn  alle  gegevens  te  vinden  die  benodigd  zijn  voor  het 
spelen  van  een  AOW-sessie.  De  presentatie  van  de  gegevens  geschiedt  in  een 
grafische  schermmode  hetgeen  betekent  dat  een  tote  en  een  map  gelijktijdig  op  het 
scherm  gepresenteerd  worden. 

2.  Bediening 

Voor  het  reageren  op  de  omstandigheden  op  de  vliegbasis  kunnen  orders  ingevoerd 
worden  met  behulp  van  een  ordermodule.  De  ordermodule  is  flexibel  van  opzet 
waarbij  het  AOW-systeem  de  gebruiker  helpt  bij  het  invoeren  van  orders  door  zo 
veel  mogelijk  taken  te  automatiseren. 

3.  Nieuwe functionaliteiten 

Op  dit  moment  is  het  niet  mogelijk  om  processen,  die  eenmaal  gestart  zijn,  af  te 
breken.  In  geval  van  gewijzigde  prioriteitstelling  kan  het  echter  wenselijk  zijn  om 
met  name  langdurende  taken  af  te  kunnen  breken.  Met  het  nieuwe  AOW-systeem 
wordt  het  mogelijk  om  processen  af  te  breken. 

Daamaast  krijgt  de  staff  de  mogelijkheid  om  orders  van  spelers  te  wijzigen  om 
zodoende  de  voortgang  van  een  sessie  te  kunnen  waarborgen.  De  staff  krijgt  toe- 
gang  tot  alle  in  het  systeem  aanwezige  (gegeven)  orders  (verleden,  heden,  toe- 
komst)  en  de  mogelijkheid  om  orders  te  wijzigen  of  te  verwijderen. 

4.  Tools 

Naast  het  AOW-systeem  worden  een  aantal  tools  ontwikkeld  voor  het  ontwerpen 
van  vliegbases,  infrastructuren,  organisatiestructuren  en  managementsstructuren. 
Tenslotte  wordt  het  ook  mogelijk  om  zelf  eenvoudig  scenario's  te  ontwerpen. 
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9.2  Hardware 

De  hardware-componenten  of  de  benodigde  faciliteiten  voor  het  AOW-III  systeem 
zijn  ongewijzigd  ten  opzichte  van  het  AOW-II  systeem.  Dit  betekent  dat  indien 
eerder  op  een  compute r-netwerk  het  AOW-II  systeem  gedraaid  heeft  dat  daarop 
probleemloos  en  zonder  aanpassingen  het  AOW-III  systeem  kan  draaien.  Zie  ook 
figuur  6.1  (pagina  33)  voor  de  fysieke  layout  van  een  AOW-netwerk. 

Wei  wordt  aangeraden  om  voor  de  stations  minstens  80486-of  pentium  pc’s  te 
gebruiken  voor  een  probleemloos  gebruik  van  het  AOW-systeem.  Het  gebruik  van 
deze  pc's  garandeert  een  hoge  verwerkingssnelheid  van  alle  aangeboden  gegevens 
vanwege  de  relatief  grote  rekenkracht  van  deze  machines. 


9.3  Omgang 

Wei  is  er  enig  verschil  in  de  omgang  met  het  AOW-III  systeem  ten  opzichte  van 
het  AOW-II  systeem.  Bij  het  oude  AOW-II  systeem  verscheen  na  het  opstarten  een 
menu  op  het  scherm  met  een  diepe  menu-structuur.  Vanuit  dit  menu  waren  alle 
modules  bereikbaar  zoals  de  tote-,  map-  en  ordermodule. 

Na  het  opstarten  van  het  AOW-III  systeem  verschijnt  een  scherm  in  grafische 
mode  van  waaruit  direct  alle  modules  bereikbaar  zijn  zonder  diepe  menustructuren 
te  hoeven  doorlopen.  Dit  systeem  is  overzichtelijker  dan  het  AOW-II  systeem 
waardoor  sneller  en  efficienter  gewerkt  kan  worden. 


9.4  AOW-III  koppeling  met  AOW-III  Tools 

Om  de  AOW-III  tools  aan  het  AOW-III  systeem  te  koppelen  moet  er  aan  de  kant 
van  het  AOW-III  systeem  het  een  en  ander  aangepast  worden.  Aan  de  kant  van  het 
AOW-III  systeem  moet  een  exercise-manager  geintroduceerd  worden  zodat  de  files 
die  geproduceerd  worden  door  het  AOW-tools  systeem  ingelezen  kunnen  worden. 
De  exercise-manager  in  het  AOW-III  systeem  heeft  de  mogelijkheid  om  aan  de 
hand  van  een  exercise-name  een  gehele  airbase  en  spelersdefinitie  in  te  lezen.  De 
exercise-manager  zorgt  ervoor  dat  aan  de  hand  van  een  naam  de  diverse  files 
worden  ingelezen. 

Wanneer  de  bovenste  rij  buttons  van  het  AOW-III  stafsysteem  beschouwd  worden 
dan  blijkt  dat  het  systeem  al  een  aantal  buttons  heeft  voor  het  inlezen  van  files 
(waaronder  scenario-files  en  het  lezen  of  wegschrijven  van  orderfiles  van  een 
gehele  sessie).  Het  inlezen  van  de  tools-gegevens  is  hier  nu  in  feite  de  nieuwe 
optie. 
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9.5  Planning  en  bouw 

Het  ontwerp  van  het  AOW-III  systeem  valt  uiteen  in  een  aantal  activiteiten,  te 
weten; 

1.  AOW-III  basisontwerp 

Het  ontwerpen  van  de  nieuwe  gebruikersinterface.  Hierin  zijn  opgenomen  de 
componenten  die  nodig  zijn  voor  de  presentatie  van  gegevens  en  de  bediening 
van  het  AOW-systeem. 

2.  Interne  functionaliteit  van  het  AOW-systeem 

Het  doel  van  het  discretiseren  van  processen  is  dat  processen  afbreekbaar  wor- 
den.  Een  gegeven  order  kan  dan  worden  gecanceled  zodat  de  gebruikte  midde- 
len  bij  een  andere  order  ingezet  kunnen  worden. 

Voor  de  staff  wordt  het  mogelijk  in  te  grijpen  in  de  orders  die  zijn  gegeven 
door  de  andere  spelers. 

3.  Tools  voor  het  AOW-systeem 

De  diverse  tools  die  voor  het  AOW-systeem  ontworpen  worden  bevatten  tools 
voor  het  ontwerpen  van  vliegbases  (infra-  en  organisatiestructuren),  draaiboe- 
ken  en  spelers-Zmanagementsstructuren. 

Een  aantal  van  de  activiteiten  die  hierboven  geschetst  zijn  worden  sequentieel 
uitgevoerd.  Het  streven  is  om  eerst  het  AOW-III  basisontwerp  af  te  ronden  en  te 
beschikken  over  een  goed  en  gedegen  gebruikersinterface.  Op  basis  van  deze 
afgeronde  gebruikersinterface  kunnen  de  diverse  resterende  punten  toegevoegd 
worden. 

De  logische  volgorde  voor  het  ontwikkeling  van  het  AOW-III  systeem  wordt  dus: 

Fase  Benaming  Betekenis 

1  AOW-III  basisontwerp  Nieuw  gebruikersinterface; 

2  Tools  Ontwerpen  van  scenario's  en  vliegbases; 

3  Interne  functionaliteit  Afbreken  van  processen  en  ingrijpen  in  gegeven 

orders. 
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Ongerubriceerd 

18.  DISTRIBUTION  AVAILABILITY  STATEMENT 

ITd.SECURITY  CLASSIFICATION 

(OF  TITLES) 

Unlimited  Distribution 

Ongerubriceerd 

ONGERUBRICEERD 


Distributielijst 
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7  t/m  9. 
10. 

11. 

12. 

13. 

14. 

15. 

16. 

17. 
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21. 
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Bureau  TNO  Defensieonderzoek 

Directeur  Wetenschappelijk  Onderzoek  en  Ontwikkeling*) 

HWO-KL*) 

HWO-KLu 

HWO-KM*) 

HWO-CO*) 

KMA,  Bibliotheek 

Instituut  Defensie  Leergangen,  LtKol.  L.  Smits,  docent  Opleidingen  KLu 
Instituut  Defensie  Leergangen,  docentenexemplaar  Opleidingen  KLu 
Directie  TNO-FEL,  t.a.v.  Dr.  J.W.  Maas 
Directie  TNO-FEL,  t.a.v.  Ir.  J.A.  Vogel,  daama  reserve 
Archief  TNO-FEL,  in  bruikleen  aan  M&P*) 

Archief  TNO-FEL,  in  bruikleen  aan  Ir.  M.J.  van  de  Scheur 

Archief  TNO-FEL,  in  bruikleen  aan  Drs.  Tj.  de  Groot 

Archief  TNO-FEL,  in  bruikleen  aan  Drs.  E.A.M.  Boots-Theunissen 

Archief  TNO-FEL,  in  bruikleen  aan  Drs.  F.G.  Smit 

Archief  TNO-FEL,  in  bruikleen  aan  Ing.  D.  Kloet 

Archief  TNO-FEL,  in  bruikleen  aan  Ing.  F.J.  Takkenberg 
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Reserve 

TNO-PML,  Bibliotheek**) 

TNO-TM,  Bibliotheek**) 
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Indien  binnen  de  krijgsmacht  extra  exempiaren  van  dit  rapport  worden  gewenst  door  personen  of  instanties  die  niet  op  de  verzendlijst  voorkomen,  dan 
dienen  deze  aangevraagd  te  worden  bij  het  betreffende  Hoofd  Wetenschappelijk  Onderzoek  of,  indien  het  een  K-opdracht  betreft,  bij  de  Directeur 
Wetenschappelijk  Onderzoek  en  Ontwikkeling. 


•)  Beperkt  rapport  (titelblad,  managementuittreksel,  RDP  en  distributiefijst). 

•*)  RDP. 


